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1.0 INTRODUCTION 


The System Management and Production Laboratory at the Research Institute, the University of 
Alabama in Huntsville (UAH), was tasked by the Microgravity Experiment Projects (MEP) Office of 
the Payload Projects Office (PPO) at Marshall Space Flight Center (MSFC) to conduct research in the 
current methods of written documentation control and retrieval. The goals of this research were to 
determine the logical interrelationships within selected NASA documentation, and to expand on a 
previously developed prototype system to deliver a distributable, electronic knowledge-based system. 
This computer application would then be used to provide a "paperless" interface between the 
appropriate parties for the required NASA documents. 


2.0 BACKGROUND AND OBJECTIVES 

The Microgravity Experiment Projects (MEP) Office of the Payload Projects Office (PPO) at 
MSFC is currently responsible for collecting and coordinating experiment/facility specifications and 
requirements between NASA and various colleges, universities, research centers, and other public- 
and private-sector organizations that are selected or are requesting to fly their respective microgravity 
experiments on designated flights. This coordination involves the communication of flight hardware 
requirements and the preparation and review of all documentation between NASA and the research 
groups. To reduce difficulties encountered by these customers of NASA, an effort was undertaken to 
research, analyze, and evaluate the current procedures involved in the information gathering 
activities. 

The MEP Office identified a need to develop an Automated Payload Experiment Tool (APET) 
which would lead experiment developers through the development planning process, obtain necessary 
information, establish an electronic data exchange avenue and allow easy manipulation/reformatting 
of the collected information. In order to fulfill this need, the University of Alabama in Huntsville 
(UAH) was tasked to design and develop the APET software package to meet the increasing demands 
to lighten the burden of documentation preparation and maintenance for NASA and its customers. 

The objective of this task was to expand on the results of the Automated Payload Experiment Tool 
(APET) Feasibility Study (previously performed by UAH) and provide procedures and software for 
the generation of experiment requirements and flight hardware requirements. The software would 
assist the scientist or engineer in generating the appropriate documentation used to develop and 
perform flight qualified experiments for the manned microgravity environment. 


3.0 CURRENT ENVIRONMENT 

The current environment of manual data gathering and information dissemination is excessively 
reliant on paper as the primary medium of transfer. This reliance on a static media adds 
exponentially to the complexity of a process that by its nature is elaborate. Changes to a document 
stored on an information media that requires physical manipulation are costly and burdensome. With 
no method in place to ensure that changes are incorporated throughout follow-on documents, (other 
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than manual verification), modifications to science, engineering, safety, and other documents are 
more susceptible to human error than necessary. 

The design, development and preparation of an experiment to fly in space are time consuming 
tasks demanding a great deal of technical and disciplinary knowledge. Reducing the time required to 
prepare an experiment and its supporting documentation is of vital interest to the Microgravity 
Science Applications Division (MS AD). Methods of developing and utilizing state of the art 
information technologies are of prime concern in simplifying the critical Principal Investigator 
(PI)/Payload Element Developer (PED) interface. 


4.JQ ACTIVITIES 

4. 1 Form and Documentation Evaluation 

UAH collected, analyzed, organized, and evaluated a number of forms and documents used in the 
current flight hardware development process. Documents were analyzed as to their content, and also 
evaluated regarding their relationships both within the same document and within other documents. 
The findings of this research were incorporated in the design of the computer software and its 
accompanying knowledge base. 

4.2 Design Considerations 

The objective of APET is to provide an easy to use tool to the Principal Investigator team. To 
ensure ease of use, few computer hardware requirements are necessary to operate the APET software 
package. 

4.2.1 Hardware 

APET is designed to run on any IBM-PC compatible personal computer. There have been five 
modules developed, four of which have been distributed. Each module's requirements depend on its 
level of complexity. These five modules are the SRD, the SRD/ERD, the Project Plan, the Science 
Requirements Envelope Document, and the Safety Requirements Document. All five packages will 
run on a 386 machine. However, while it is possible to use the SRD/ERD system on a 386 PC, it is 
recommended that the APET user install the software on a 486 PC or higher. The graphical displays, 
multiple screen windows, and the complexity of the system cause noticeable slowdowns on any 
machine less than the 486. 

The software requires that the PC be equipped with a hard disk drive. For proper execution, the 
hard drive (or some partition of it) must be named C: . The SRD/ERD version of APET will require 
approximately 14M (megabytes) of space on the hard drive for the system, plus another 1M on the 
hard drive for the data files created by the user. However, for optimal performance, the hard drive 
should have a total of at least 17M free upon installation of the software. The Project Plan, the 
Science Requirements Envelope Document, and the Safety Requirements Document will each require 
from 1M - 3M of hard disk space. 
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For ease of use, the PC should be equipped with a mouse. This, however, is not mandatory. 
APET utilizes hypertext technology as the user interface. Hypertext software systems allow for the 
retrieval of related information at the point and click of a mouse or, if a mouse is not used, at the 
touch of one or two keystrokes. For information on a highlighted topic, the user should move the 
mouse to that word and click. A window will be opened, overlaying the current screen. Once the 
information is reviewed, the user can press the space bar and close the window, returning the user to 
the previous screen. 

4.2.2 Software 

One of the primary objectives in developing the APET was to reduce the confusion of the 
documentation process. This guiding principle was instrumental in the design of the software as well. 
All APET software packages use a standardized format for the user interface. Screen design, menu 
selection, method of data entry, and user messages take the same form throughout the APET 
packages. 

In developing the questions and knowledge base for the APET, it was assumed that all necessary 
instructions for successful completion of PI requirements were contained in the hardcopy documents. 
Therefore, to formulate user prompts, questions, explanations, etc., the questions and background 
information were taken directly from the applicable document. Definitions were taken from pertinent 
entries within the applicable document. When conflicting definitions were found to exist, the most 
logical definition was used in that software section. 

4.3 Software Packages 

4.3.1 Science Requirements Document 

According to the Microgravity Science Applications Division (MSAD) Management Plan, "The 
Science Requirements Document (SRD) is the basic document which levies the science requirements 
on the hardware. As such, the document must first provide adequate justification for conducting the 
experiment in space and then delineate and justify the individual science requirements. The science 
requirements include the observational and environmental data requirements necessary to meet the 
science objectives". 

The SRD is the first documentation requirement to be met by the Principal Investigator. It was 
also the logical beginning for the APET software. The SRD section of APET consists of a query of 
52 questions concerning the description of the experiment, the limitations of non-space testing, and 
the potential benefits from the space environment. The answers to these questions are narrative in 
form (unlike other parts of APET, which are more fill-in-the-blank or choose from a list). User 
prompts for these questions were taken directly from the MSAD Management Plan. The user has the 
option of answering these questions sequentially or randomly (see Appendix A). An option also exists 
to answer only the unaddressed questions, so that at any time the user can see how many questions 
remain. There are a number of options available to the user to make the documentation process more 
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efficient. For example, during the question/answer session, the user has the option of viewing/editing 
related answers on selected questions. This adds to the consistency of the material, and provides an 
easier data retrieval method for the user. For a full description of the SRD software package, see the 
SRD/ERD User Guide (Appendix A). 


4.3.2 Experiment Requirements Document 

The Experiment Requirements Document (ERD) is used by the payload element developer and/or 
the principal investigator to define experiment requirements to be accommodated by the Space 
Transportation System (STS) for a given mission. The ERD is the logical follow-on document to the 
SRD. While the SRD justifies the need for a space environment and generally describes experiment 
requirements, the ERD expands on these generalities and requires specific experiment specifications. 

Because of the more exacting nature of the ERD, the user faces more demands to respond to 
questions with exact numbers rather than narrative descriptions. Therefore, the ERD user prompts 
will often ask for a number or word to be selected from a limited list of appropriate answers, or 
supply a short (one or two word) answer to the software query. Because of the more demanding 
requirements of the ERD, the software has a much deeper level of complexity. Questions with a 
limited number of answers or questions that require logical (YES/NO) responses can be checked 
against previous answers to ensure that conflicting or mutually exclusive responses are not accepted. 
This built-in "expertise" adds much to the integrity of the user supplied data, and thus makes the 
information contained in the ERD more consistent and useful. 

The ERD section of APET is a great deal larger than the SRD. There are twelve sections of the 
ERD, several of which taken separately would be as large as the SRD in its entirety. However, based 
on the requirements of the experiment, complete sections of the ERD can be eliminated. The ERD is 
also more technically complex than the SRD, containing far more terminology, acronyms, etc. than 
the other APET modules. Therefore, the use of hypertext definitions, examples, graphics and 
hypertext reference sections are more widely used in the ERD. 

The most critical of the ERD sections is the first, which deals with the experiment's functional 
objectives. Each experiment contains one or more functional objectives, which in turn are composed 
of one or more steps. Follow-on sections in the ERD refer back to and are based on the answers 
given in ERD Section One. The APET software helps the user by requiring that Section One be 
completed before these follow-on sections, and also aids by ensuring that if a functional objective is 
deleted, that the follow-on sections that refer to that deleted functional objective will also be deleted. 
Again, this adds to the consistency of the material, and provides an easier documentation method for 
the user. A full description of the ERD software package is contained in the SRD/ERD User Guide 
(Appendix A). 


4 


4.3.3 Project Plan 


The Project Plan is the basic planning document that describes the overall plan for proceeding 
with the project. Project Plans are unique to each project and the format and level of detail vary with 
the size, complexity, sensitivity and other characteristics of the project. The Project Plan will cover 
the project to completion, including operational and data analysis periods. The Microgravity Science 
and Applications Division (MSAD) requires that a MSAD Project Plan be submitted and approved 
prior to making a major commitment of resources to an MSAD project. MSAD Project Plans are to 
be prepared in final draft form for the Requirements Definition Review. 

Plans will be prepared and submitted for all flight experiments. Project Plans will be reissued, 
modified, or amended for reflights depending on the complexity of the task. A plan's preparation is 
the responsibility of the designated Project Manager at the responsible NASA center. The Project 
Manager will sign the MSAD Project Plan as the preparer; the Project Scientist and the Principal 
Investigator will sign as concurring. The MSAD Project Plan will be signed off at the NASA center 
prior to submission to Headquarters by the appropriate center's authorities. When the Program 
Scientist and Program Manager sign to register their concurrence, the MSAD Project Plan will be 
submitted to the MSAD Director for approval. 

The Project Manager is responsible for updating a MSAD Project Plan when significant changes 
occur (such as changes in scope, organization, or roles and responsibilities). This does not apply to 
resources, schedules or manpower, which are updated through normal budgeting and project 
monitoring activities. The Project Manager will establish a change control process for maintaining 
the MSAD Project Plan and other project documentation. 

The Project Plan component of APET is similar to the SRD component, in that it is comprised 
primarily of text responses to a series of predefined questions. There are a number of options 
available to the user to make the documentation process more efficient. For a full description of the 
Project Plan software package, see the Project Plan User's Guide (Appendix B). 

4.3.4 Science Requirements Envelope Document 

The Science Requirements Envelope Document provides an envelope or volume of science 
requirements for a type of experimentation which is intended to encompass the science requirements 
generated by individual experiments of that type. The primary purpose of the document is to provide 
science requirements against which hardware can be conceptualized such that later, when specific Pis 
are chosen, their individual requirements will fall within the requirements originally stated in the 
Science Requirements Envelope Document. 

The Science Requirements Envelope Document is very similar to the SRD. The primary 
difference is not the questions, but in the user responses, where a range of values is given for a 
capacity rather than a discreet measurement for an experiment. To complete the Science 
Requirements Envelope Document, questions were taken directly from the MSAD Management Plan. 
For a detailed description of the Science Requirements Envelope Document, see Appendix C. 
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4.3.5 Safety Requirements Document 


The purpose of the Safety Requirements Document is to delineate the activities and documentation 
requirements leading to safety certification of instruments, facilities, Mission-Peculiar Equipment 
(MPE), and Instrument Ground Support Equipment (IGSE) that constitute a National Space 
Transportation System (NSTS) Payload or payload complement for which the Payload Project Office 
(PPO) has management and integration responsibility. The Safety Requirements Document designates 
the safety-related activities and documentation required of individual Payload Element Developers 
(PEDs). This document is applicable to all MSFC PPO managed STS attached payload missions and 
to all of the PEDs for those missions. STS attached payloads include Spacelab dedicated missions, 
middeck payloads, and partial-payload missions. A partial-payload mission is a flight that is not a 
Spacelab-dedicated (unique) mission and is shared with other payloads. Such missions are also 
referred to as mixed cargo missions. Partial payloads are defined as those payloads that do not 
require a Spacelab module or the Spacelab igloo. 

As with the previous APET components, completion of the Safety Requirements Document 
involves answering a series of predefined questions. The answers to these questions may be given in 
the form of short narratives, or as choices from lists of possible answers. For ease of data storage 
and retrieval, the answers are stored in a directory according to the phase of the review in which the 
questions are associated (i.e. Phase 0, Phase 1, etc.). For a detailed description of the Safety 
Requirements Document, see Appendix D. 


5 , 0 P RELIMINARY RESUI TS OF S O FTWARE DIST RIB UT I ON 

To solicit inputs about the APET software package, presentations and demonstrations were 
conducted for selected Pis at Marshall Space Flight Center, Huntsville, AL, Lewis Research Center 
in Cleveland, OH, and at NASA headquarters in Washington, D.C., where instruction manuals and 
system software were distributed. The primary emphasis was on the validation of the SRD package, 
and limited emphasis was on the ERD package. Emphasis was placed on the SRD because it is the 
first document to be completed by the PI and is due 12 - 36 months before the ERD. In addition, two 
packages for the generation of the Project Plan were distributed. Currently, no packages addressing 
the Science Requirements Envelope Document or the Safety Requirements Document have been 
dispensed. 

The preliminary results of these distributions have been favorable. The first SRD software 
package was distributed on diskette only, with no supporting documentation. Even so, the user was 
able to generate an acceptable SRD with minimal instruction from the UAH APET development staff. 
Two more SRD packages have since been evaluated by potential users, and while both found the 
software to be useful, both were primarily Macintosh users and opted not to produce the SRD using 
the APET software. After evaluation of the Project Plan, it was determined that the schedule 
examples found in the Development Approach section (Section 4.4.3) currently displayed in the 
package were inadequate. After working with selected Project Managers, a better understanding of 
scheduling requirements and development was obtained. This understanding resulted in an updated 
Project Plan co nta ining improved schedule examples. Comments from these and other early users of 
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the system have found it user-friendly, and an aid in meeting the documentation requirements. Users 
have been complimentary about the ease of data retrieval. 

Although the ERD component of APET has been distributed, none of the early PI participants 
have completed any ERD sections. Likewise, the software distribution addressing the Project Plan 
has not yielded any conclusive results. Recipients of the software have been impressed with the work 
NASA and MSFC have put into this effort, and all have agreed that the research completed is a 
valuable and needed first step in automating the documentation process. 


6.0 LIMITATIONS OF DELIVERED SOFTWARE 

The most valuable comments made about the APET software are not the compliments, but the 
criticisms. Without the customer inputs of what is still required in the system, it would be difficult to 
determine the improvements necessary to make it a valuable tool for the PI. The following 
paragraphs represent the most common suggestions on improving the APET tool. 

The APET software was designed to run on any IBM-compatible personal computer (PC) using 
the DOS operating system. This requirement thus restricts users of the Macintosh line of computers 
and their associated operating system. The determination to build for the PC and not the Macintosh 
was made primarily because little application software exists for the Macintosh that offers the same 
support that Knowledge Pro offerers for the PC. However, because the NASA PI community’s 
alliances seem to be evenly split between PC and Macintosh, it is a reoccurring suggestion that the 
Macintosh be supported. Efforts to convert the existing PC code to a form that can be executed on 
the Macintosh are currently being investigated. In an attempt to find a successful conversion 
package, the software package SoftPC by Insignia® Solutions was evaluated. SoftPC is a Macintosh 
application which enables the Macintosh to emulate a high specification IBM PC/AT compatible 
computer. This, however, proved not to be a viable solution because the amount of random access 
memory (RAM) required to support certain portions of the APET software package could possibly 
exceed the amount of RAM available on most Macintosh computers causing the system to fail. 

The second common suggestion is that the APET editor be improved to include a spell checker 
function. This was realized to be a shortcoming of Knowledge Pro from the outset of the software 
development project. The exclusion of a spell checker function is primarily attributable to the lack of 
random access memory of the current generation of personal computers. RAM is required for both 
APET, Knowledge Pro, and the Knowledge Pro editor. The addition of an internal spell checker 
would increase the requirements of RAM to the point of system failure. The proposed solution for 
the lack of a spell checker is to include an external spell checker that can be called by APET. In 
order to add this feature, a spell checker software package that is inexpensive and free to distribute 
must be found. Attempts have been made to furnish an acceptable spell checker, however no suitable 
package has of yet been found. At this point, the conversion of APET to a Windows operating 
environment my be the best alternative for overcoming this obstacle. 

Most other suggestions about the APET software are not necessarily criticisms of the package but 
of the documentation process. For instance, Pis preparing to fill out the SRD commented that many 
of the questions asked did not pertain to the objective of the SRD. In those cases, it was explained 
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that all questions came from the MSAD Management Plan. However, there has been enough 
commentary generated to justify that this is a valid concern within the PI community. The SRD 
should be examined for what information is needed to meet its objective, and eliminate any irrelevant 
questions that may exist. 


7.0 CONCLUSIONS AND RECOMMENDATIONS 

The APET package has been developed and distributed to Pis required to submit SRDs and ERDs 
to justify/define their experiments. Additionally, software has been developed and is currently being 
distributed/evaluated to fulfill the documentation requirements for Project Plans and Science 
Requirements Envelope Documents. Initial software efforts have begun on the Safety Requirements 
Document, with the prototype design being developed. Based on the preliminary comments of the Pis 
who have taken part in the distribution of the APET software, APET fills a need to automate the 
documentation process. However, more work needs to be done to enhance the APET system. 

There should be a Macintosh version of APET available. There are a number of Pis who wish to 
use the software, but are unhappy with the PC-only restriction. The editor of the APET software 
should also be enhanced to include additional features, such as a spell checker. This recommendation 
may be delayed, however, until machines with a greater RAM are available on the market. 

It is also recommended that the findings of this research be used to examine the documentation 
requirements placed on the PI. There are instructions in the NASA-supplied hardcopy documentation 
that are vague and have little or no relationship to the true objective of the master document. These 
instructions also offer little information as to the amount of detail required to adequately answer the 
question. These questions cause problems for the PI, and add unneeded complexity to the overall 
task. 

Once a number of SRDs have been created using APET, it is suggested that the software be 
modified to include examples of what is expected from the PI. This could further be developed to 
provide the PI a model that could be copied into his answer, then customized to his individual 
response. 

Further work should be conducted to complete the Safety Requirements Document’s Material 
Usage Listing. This will be of great benefit to the PI, who is unlikely to be aware of the dynamic 
nature of the hazardous materials database. This work, along with the completed validation/ 
distribution of the Project Plan and the Science Requirements Envelope Document, will provide a 
solid baseline from which NASA can move from a paper environment to an electronic environment. 
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1.0 INTRODUCTION 


So you want to fly an experiment on the Shuttle. 

Well, to begin the process, we must get a little information about your experiment and its 
requirements. 

If you have flown with us in the past, you may remember a substantial amount of paper 
documentation was required. This application, the Automated Payload Experiment Tool, is 
designed to alleviate much of the burden of the document preparation and maintenance 
process. This system can currently be used to prepare two support documents, the Science 
Requirements Document (SRD), which defines the science objectives, and the Experiment 
Requirements Document (ERD), which defines the experiment design/build requirements. 
The version that you have is for the creation of both documents. 


2.0 DISCUSSION 

2.1 Background 

The Microgravity Experiment Projects (MEP) Office of the Payload Projects Office 
(PPO) at the Marshall Space Flight Center (MSFC) is currently responsible for collecting and 
coordinating experiment/facility specifications and requirements between NASA and various 
colleges, universities, research centers, and other public- and private-sector organizations 
that are selected or are requesting to fly their respective microgravity experiments on 
designated flights. This coordination involves the communication of flight hardware 
requirements and the preparation and review of all documentation between NASA and the 
research groups. To reduce difficulties encountered by these customers of NASA, an effort 
was undertaken to research, analyze, and evaluate the current procedures involved in the 
information gathering activities. 

The MEP Office identified a need to develop an Automated Payload Experiment Tool 
(APET) which would lead experiment developers through the development planning process, 
obtain necessary information, establish an electronic data exchange avenue and allow easy 
manipulation/reformatting of the collected information. In order to fulfill this need, the 
University of Alabama in Huntsville (UAH) was tasked to design and develop the APET 
software package to meet the increasing demands to lighten the burden of documentation 
preparation and maintenance for NASA and its customers. 

2.2 System Requirements 

The objective of APET is to provide an easy to use tool to the Principal Investigator (PI) 
team. To ensure ease of use, few computer hardware requirements are necessary to operate 
the APET software package. 


APET is designed to run on any IBM-PC compatible personal computer. While it is 
possible to use the system on a 386 PC, it is recommended that the APET user install the 
software on a 486 PC or higher. The graphical displays, multiple screen windows, and the 
complexity of the system cause noticeable slowdowns on any machine less than the 486. 

The software requires that the PC be equipped with a hard disk drive. For proper 
execution, the hard drive (or some partition of it) must be named C:. The SRD/ERD version 
of APET will require approximately 14M (megabytes) of space on the hard drive for the 
system, plus another 1M on the hard drive for the data files created by the user. However, 
for optimal performance, the hard drive should have a total of at least 17M free upon 
installation of the software. 

For ease of use, the PC should be equipped with a mouse. This, however, is not 
mandatory. APET utilizes the hypertext technology, which offers a point-and-click user 
interface. Instead of a mouse, the user does have the option of pressing selected function 
keys to achieve the same effect. 

2.3 Installation 

The APET software package is provided on four high density diskettes. The files stored 
on these diskettes have been compressed; therefore, it is required that the user follow several 
simple steps to ensure correct installation. 

1) Insert the diskette marked as "APET SRD/ERD DISK 1" in the drive designated as 
A:. If the A: drive on your system is not the correct size, then use the DOS ASSIGN 
command to redesignate the drives appropriately. (For example, if you have 3 1/2" disks but 
your 3 1/2" drive is B:, then at the DOS prompt type ASSIGN A: B:.) 

2) From this drive (A:) type: 

INSTALL. 

This will activate the installation routine. A series of instructions and informational text 
will be presented. Each screen will advise what is transpiring in the installation procedure. 
The installation routine will create a subdirectory on the C: drive called GARDEN. Once 
created, the files contained on the installation disks will be copied to the directory 
C:\GARDEN. Most of these files have been compressed to conserve disk space. An 
uncompress routine will be invoked to return these files to their normal (and usable) condi- 
tion. As the installation routine is completed for each disk, the user will be advised to insert 
the next diskette. To cancel the installation at any time, press the CTRL (control) C keys. 

3) Upon successful installation of the APET program files, the message 
INSTALLATION ROUTINE COMPLETE will be displayed. The APET application, run- 
ning under the direction of Knowledge Pro software, will be entered and you will be 
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presented the opening menu. All subsequent sessions using the APET software may be 
initiated by going to the C:\GARDEN subdirectory and typing FLY. 

2.4 Getting Started 

This application uses hypertext technology. Hypertext software systems allow for the 
retrieval of related information at the point and click of a mouse or, if a mouse is not used, at 
the touch of one or two keystrokes. For information on a highlighted topic, just move the 
mouse to that word and click. A window will be opened, overlaying the current window. In 
the new window, the information will immediately be displayed. Once this support 
information has been reviewed, press SPACE (or ESC) once to close the window and return 
to your original screen. If you are not using a mouse, please use the F3 and F4 function 
keys (marked Select and View) as indicated at the bottom of the screen, (see Figure 1). The 
F3 key allows you to select the different hypertext topics. Once the desired topic is selected 
(i.e. highlighted), the F4 key calls the background information for view. 

Multiple page displays are indicated by the Page 1 of 2 message at the lower right of the 
screen. To navigate through multiple screen displays, please use the Page Up and Page 
Down keys to scroll either forward or backward through the pages. 

— "Automated Payload Experiment Tool" 

So you want to fly on the Shuttle. 

Well before you can, we must get a little information about 
your experiment and its objectives. 

If you have flown with us in the past, you may remember a substantial 
amount of paper documentation was r equired. This application, the 

is designed to alleviate much 

of the burden of the mm|| preparation process by utilizing a^l, 
knowledge-based system. This system can currently be used to prepare 
two of our support documents, the Science Requirements Document (SRD), which 
defines the science objectives and the Experiment Requirements Document (ERD), 
which defines the experiment design/build requirements. 

Press SPACE to continue. 


FI Help 

F3 Select 


Pg 1 of 1 

Space Cont. 

F4 View 

F8 DOS 

F10 Quit 


Figure 1 

Sample Screen Layout Using Hypertext 

For help at anytime throughout the APET application, press the FI key. This will 
retrieve location sensitive help information, and may be called from the system or system- 
called edit screens. This will be the method by which assistance information will be 
retrieved throughout this application. 


3 






APET has been designed as a menu-driven software package. This means that any 
function required of the user can be activated via a menu option. This includes exiting the 
system. It is strongly recommended that the user always "back out" of the application by 
using the appropriate menu options, i.e. "Return to Previous Menu". An option does exist to 
exit from any point in the application by selecting F10. It is not recommended that this be 
used from inside a question/answer section of the application. The F10 command causes an 
immediate exit from the program, without checking to ensure that open files have been 
properly saved. Therefore, the user may experience data loss if the application is exited in 
this manner. 

After the installation and initial use of the APET software, future sessions will be 
initiated by going to the C:\GARDEN subdirectory and typing FLY. This will activate the 
software and present the opening menu, (see Figure 2). 


r — "Automated Payload Experiment Tool" 


Please select the activity of your choice, or choose Exit 
to leave the system. 


How to use the System 

Project Selection 

SRD Overview and Explanation 

ERD Overview and Explanation 

SRD Documentation Cross-Reference 

ERD Documentation Cross-Reference 

Glossary/Acronyms 

Print Glossary/ Acronyms 

Exit System 





FI Help 




F8 DOS 

F10 Quit 


Figure 2 

Opening APET Main Menu 


Due to the hypertext capabilities of the APET software, a large amount of RAM (random 
access memory) is required. Because of the heavy RAM demand, proper execution of the 
software requires no other software package be running simultaneously with the APET 
software. Whenever the available RAM becomes too little for the application, an 
"Insufficient Memory" message will be shown at the bottom right of the screen. To alleviate 
this situation, simply get out of APET and reboot the system. This will usually free up all 
available RAM and ensure proper execution, (see Helpful Hints for further instruction.) 
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3.0 USING THE APET SYSTEM 


3.1 How to Use the System 

Because the use of a hypertext tool may be a new experience, a brief on-line tutorial is 
provided with APET. To use this tool, please choose option one on the opening menu 
entitled "How to Use the System". To select this option, point with the mouse to the phrase 
and click. If not using a mouse, use the arrow keys to highlight the option and press 
RETURN. You can tell when an option has been selected because it (the phrase or word) 
will be highlighted differently from all other options. As the mouse is moved to other 
options, each in turn will be highlighted. 

Once the "How to Use the System" option has been selected, a different screen will be 
presented with a brief overview of hypertext and the methods of selecting topics. (This 
overview is much the same as appears in Section 2.4 of this user's guide.) Practice selecting 
topics and moving from one screen to another using either the mouse or the appropriate 
keyboard function keys. 

3.2 Project Selection 

The APET software package will accommodate one or more experiments for the user. 
However, each experiment must be identified by a short (8 characters or less) name, which 
must conform to the naming convention used by the DOS computer operating system. 
Briefly, these rules state that a DOS name cannot be over 8 characters in length, and must 
contain a combination of either letters, numbers, or the underscore (_) character. Any other 
special keys, including the SPACE, are prohibited. The rationale behind this naming 
convention is to allow storage of data files for each experiment in a subdirectory for that 
specific experiment. For example, if a user is working on two experiments, identified as 
THINFILM and HIPROTEN, then there would be a subdirectory for each. The 
configuration of these files would be as follows: 

R oot D i rectory Ap p lication D i rectory E xperiment D i recto r y 

C:\ GARDEN\ THINFILM 

HIPROTEN 

Therefore, all data files containing answers for the APET questions for the experiment 
THINFILM would appear in the subdirectory THINFILM. If additional experiments are 
required, the user would identify the new experiment and an additional subdirectory would 
be added. 

Figure 3 shows the menu for selecting, adding, or deleting an experiment project. In the 
example, the experiment AADSFJL has been previously defined by the user. If the user 
wants to work on this experiment, he simply points and clicks on this selection. (This would 
be the case in a majority of the cases, since most Principal Investigators will have only one 
active experiment at any given point). However, if another experiment is required, the user 
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would click on "ENTER A NEW PROJECT". The user would be prompted to identify the 
new experiment, and would immediately be passed into the APET system, where information 
regarding that experiment would be addressed. 

[— "Automated Payload Experiment Tool" 1 


Please select the project of your choice, or enter a new 
project. 


AADSF_L 

ENTER A NEW PROJECT 
DELETE AN OLD PROJECT 
RETURN TO MAIN MENU 


i 1 

FI Help 

F8 DOS 

F10 Quit 


Figure 3 

Project Selection/Identification Menu 

If a user wishes to delete an experiment, along with all its associated data files, he may 
do so by selecting the "DELETE AN OLD PROJECT" option from the menu. However, 
there is no recoverable procedure to undelete a project. Therefore, the user is strongly 
advised to use this procedure with caution. 

3.3 SRD Overview and Explanation 

The third selection from the APET Main Menu is the "SRD Overview and Explanation". 
This option should be selected when the user wishes to see an overview of the SRD 
document, along with brief explanations of the information to be covered in each 
section/subsection of the document. For an additional overview of the topics to be addressed 
in the SRD, see Appendix A of this document. 


3.4 


Explanation 


The fourth selection from the APET Main Menu is the "ERD Overview and 
Explanation". This option should be selected when the user wishes to see an overview of the 
ERD, along with brief explanations of the information to be covered in each 
section/subsection of the document. For an overview of the topics to be addressed in the 
ERD, see Appendix B of this document. 
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3.5 SRD Documentation Cross-Reference 


The fifth selection from the APET Main Menu is the "SRD Documentation Cross- 
Reference". Selection of this option allows the user to more fully understand the 
interrelationships between the Science Requirements Document (SRD) and the other 
documentation required by NASA. The SRD has sections that reference information 
contained in other sections of the SRD as well as other documents. Only the highlighted 
topics are further referenced. 

3.6 ERD Documentation Cross-Reference 

The sixth selection from the APET Main Menu is the "ERD Documentation Cross- 
Reference". Selection of this option allows the user to more fully understand the 
interrelationships between the Experiment Requirements Document (ERD) and the other 
documentation required by NASA. The ERD has sections that reference information 
contained in other sections of the ERD as well as other documents. Only the highlighted 
topics are further referenced. 

3.7 Glossary/ Acronyms 

A number of NASA specific terms, definitions, and acronyms will appear as support 
material throughout the documentation process. One of the primary advantages of using a 
hypertext-based tool is to allow for easy and immediate retrieval of these terms. 

Option number seven from the APET Main Menu allows the user to retrieve a listing of 
these terms, and presents them in a form analogous to a glossary in a book. To view a 
definition, highlight the desired term and click. A term can be highlighted by using the 
mouse to move the cursor to that word, or by using the F3 key for selection. To view the 
definition, the user should either click the mouse or press the F4 key. The definition of that 
word/term will be presented. Should the definition contain a term that requires further 
description, highlight that word and click. The new definition will overlay the previous 
definition. This method can be repeated as long as further definitions exist and the memory 
capacity of the machine is not exceeded. 

Please note that the glossary consists of multiple pages. Remember to navigate through 
the multi-page displays by using either the Page Up/Page Down function keys. 

3.8 Print Glossarv/Acronvms 

Option number eight from the APET Main Menu activates a routine for the printing of 
the glossary /acronym list, as discussed in Section 3.7. Because the output of this selection 
will be a multi-page document, the use of this option will be rare. 
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3.9 Filling Out the SRD 


To fill out the SRD, the user must first select "Project Selection" from the APET Main 
Menu. Then the Project Selection/Identification Menu (Figure 3) will be presented for the 
user to identify either a new project or select an existing project. Once the 
selection/identification has been made, the SRD/ERD Activity Menu (Figure 4) will be 
presented. Please note that the selected project is shown on the upper right comer of the 
screen. Please be sure that the project shown is the one you wish to work. 


"Automated Payload Experiment Tool" 


The project you have selected is: AADSF_L 
Please enter your choice of activities from the list. 


FILL OUT DOCUMENTATION 
PRINT SRD 
PRINT ERD 
DISPLAY SRD 
DISPLAY ERD 

CREATE AN ASCII FILE OR SRD 
BASELINE DOCUMENT 

COMPARE BASELINE TO CURRENT REVISION 

COPY ANSWERS TO DISK 

RETURN TO PREVIOUS MENU 

RETURN TO MAIN MENU 

QUIT 


FI Help 


F8 DOS F10 Quit 


Figure 4 

SRD/ERD Activity Menu 


The SRD/ERD Activity Menu presents eleven options for the user. The most significant 
of these is the first: "FILL OUT DOCUMENTATION". The selection of this option will 
present the Fill Out SRD/ERD Documentation Menu (Figure 5). This menu offers the user 
three options: "ENTER PROJECT INITIALIZATION INFORMATION", "COMPLETE 

SCIENCE REQUIREMENTS DOCUMENT (SRD)", and "COMPLETE EXPERIMENT 
REQUIREMENTS DOCUMENT (ERD)". 
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FI Help 




F8 DOS 

F10 Quit 


Figure 5 

Fill Out SRD/ERD Documentation Menu 


3.10 Entering Project Initialization Information 

Under most circumstances, the first information entered by the user into the APET 
system is the project initialization information. To enter this information, select option one 
from the Fill Out SRD/ERD Documentation Menu. This information is used to identify 
certain aspects of the experiment, and will be used throughout the documentation process. 
Entries include the PI name, organization, address, city, state, zip, phone, and experiment 
title. This information will be provided in the form of type written responses to user 
prompts. For example, the user will be asked: 

Please enter your first and last names, i.e. Dr. John Doe. 

The user should respond with a one line response. (If there is a limitation on the length 
of this one line response, the screen display will provide an instruction, such as "Please limit 
your response to 16 characters.") This will be the format of user entries throughout the 
APET application. When the user is prompted to make an entry, the response should be on 
one line. When the user responds with a RETURN, the answer is stored and the next 
question, if one exists, is asked. Once all questions for that segment have been answered, 
the answers are written to a data file. 

In the "Project Initialization Information" subsection, the only variation in the user 
prompt/one line response routine is with the experiment title. Because experiment titles can 
be several lines, the user is given a prompt and immediately sent to the APET editor. This 
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editor is a small version of a word processor, with many of the functions of a common word 
processing package. The commands used in the APET editor are similar to those in the 
software package WORDSTAR. To see the commands available, press the FI function key 
from inside the editor. A separate window will be opened and will overlay the current 
screen. From there, page down until the function you wish to perform is shown. The one- 
to-two keystroke command to accomplish the task will be shown. (Note: The symbol O 
represents the CONTROL key., i.e. A KQ means to hold the CONTROL key down while 
pressing the letter K, then press the letter Q.) When the user is finished entering the answer 
into the editor, he may exit by pressing the ESC (escape) key. A message will then appear 
on the screen that tells the user what file name is being saved. Respond with a RETURN to 
accept this name and save the answer, or an ESC to cancel the answer. 

Important: Do not change the file name when the APET software asks if the name is 
acceptable. Future sessions that allow the user to change, delete, print, or display the SRD 
answers require that these file names be used. Changing the file name will make the file 
either inaccessible or inappropriate. Therefore, always accept the file name as given. 

3.11 Complete Science Requirements Document 

To complete the Science Requirements Document, there are usually between 50 - 60 
questions that must be answered. These answers will be in the form of short narratives, 
consisting of one or more paragraphs of text. Each question or user prompt will invoke the 
APET editor and give the user sufficient space to write as much (or little) as required. (For 
an outline of the topics to be addressed, see Appendix A.) A sample question from the SRD 
is shown in Figure 6. 

Description of experiment (Question 1 of 52) 

Please enter a narrative description of the experiment . 

This topic is also addressed under the heading 

"Experiment Procedures to be Used." 

Press the RETURN KEY to enter the editor, 

ESC to leave the editor, and RETURN to confirm save. 

— C:\GARDEN\AADSF_L\EXPDESC.DAT 

The body of the text goes in this area. This is the description of the experiment. 


Fl Help 

F3 Select 


Pg 1 of 1 

Space Cont. 

F4 View 

F8 DOS 

F10 Quit 


Figure 6 

Sample SRD Question Screen 
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The Complete SRD session begins by asking the user if he has begun to fill out the SRD 
previously. A 'NO' response causes the questions to be asked in sequence. A 'YES’ 
response results in the question topics to be displayed in a list. If questions are to be 
answered from a list, a list will appear as a window that overlays the question screen. The 
user is expected to point-and-click on the appropriate topic. (If not using a mouse, use the 
arrow keys to select and press RETURN.) The user should click on the appropriate answer 
with the left-side mouse button. 

For the initial SRD session, the user would respond with a NO and proceed to the 
questions. These questions will be asked in the same sequence as is shown in the outline. 
After each response, the user will be asked if he wants to continue to the next question. This 
gives the user a chance to end the session when desired, rather than advancing through all the 
remaining questions. The title of each question screen will include the number of the 
question (i.e.. Number 1 of 52). This allows the user to see where he is in the process and 
act accordingly. 

If the user responds with a 'YES', which means there has been a previous session, the 
following question will appear: 

Do you wish to change only one item, resume at a point 
and continue sequentially through the remainder of the 
SRD, or complete all topics previously unanswered? 

This allows the user one of three options. 1) He may select the one answer that needs 
changing, go directly to that answer and change it, then record that answer to disk. 2) He 
can select the topic where he would like to resume his activities, answer that question, record 
the answer, and go to the next question in sequence. This gives the user the capability of 
selecting the 20th question, and proceed sequentially through the remaining 32 questions. 3) 
The user can complete all questions that have not yet been answered. This option will 
invoke a command to look at what answers (files) do not exist, and build a list of these 
topics. The user then selects the topic to answer, answers the question, records the answer, 
and goes to the next question of his choice. With each recorded answer, that topic is 
removed from the list. 

3.12 Mark Questions in the SRD as 'Not Applicable' 

The SRD questions used in APET are taken directly from the Microgravity Science and 
Applications Division (MSAD) Management Plan. However, the PI and his NASA project 
manager may determine that some of these questions do not pertain or are not necessary for 
the completion of the SRD. In order to simplify the SRD preparation process, the ability to 
mark multiple questions as 'Not Applicable' has been provided. This option would probably 
be chosen as one of the first actions taken in preparing the SRD. 
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Upon selecting this option from the menu, the user will be requested to choose the topics 
to mark as "Not Applicable" by one of the below two methods. This choice depends on 
whether a mouse is being used. For mouse users, topics will be selected by clicking the 
RIGHT side mouse button on each topic to be marked. When the list is complete, click the 
LEFT side mouse button. To navigate through the multiple page listing, click on the Page 1 
of 4 message at the bottom of the list. 

Non-mouse users are instructed to use the arrow keys to move to the topic to be selected, 
then use the INSERT key to select it. To move from one page to another, use the Page 
Up/Page Down keys. When the list is complete, press the RETURN key. 

All topics selected will be given the answer 'Not Applicable'. However, any questions 
that have been previously answered will not be changed, and a warning message to that effect 
will appear on the screen. This safeguards against the user accidentally destroying a valid 
answer by choosing this option. If an answer is required to be changed to 'Not Applicable', 
then the user must select the topic from the 'Change One Item' option (see Section 3.11). 

3.13 Printing the SRD 

The user has three methods available to generate output from the APET software. These 
include printing the document, displaying the document, and creating an ASCII file of the 
document. The APET application was designed to be flexible enough to go to a variety of 
printers. As with most output, the best results will be with the use of a laser printer. If a 
laser printer is not available, the use of a dot-matrix printer will also be acceptable. A 
variety, although not nearly exhaustive, of dot-matrix printers have been tested with the 
APET software, and all have performed well. 

If the document has previously been baselined (discussed later in Section 3.21), then a 
menu will appear giving the user the option of printing the document from the baselined 
version, the current revision, or neither version. If the neither option is chosen, then it is 
assumed that the user does not want the document printed, and the program will 
automatically return to the previous menu. If the baseline option is chosen, then the 
document will be printed from the file which is in the project baseline subdirectory. If the 
current revision option is chosen, then the document will be printed from the version of the 
document which the user is currently revising. If the document has not been baselined, then 
the document will be printed from the current version. 

The printing of the SRD will generate the document in its entirety. An initial page eject 
will normally (depending on printer type) advance a blank sheet of paper before the cover 
sheet is printed. This will be followed by a second page advance, then page one of the 
document will be printed, followed by two, three, etc. through the end of the document. 
Because there are often graphics, tables, etc. that must be inserted within the textual 
document, no table of contents is printed. Because of the limitation of graphics support, it is 
suggested that all externally generated graphic illustrations, tables, etc. be provided in an 
appendix, with appropriate references throughout the document. 
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While the print procedure is active, a message will appear in the lower left of the screen. 
No other activities may take place while the document is printing. In case the printer runs 
out of paper, an error message will appear. Reload paper in the printer and press the 
SPACE key to continue. 

3. 14 Displaying the SRD 

The second method of generating output using APET is to display sections of the SRD to 
the screen. The SRD is divided into seven major sections, with each divided into one or 
more subsections (see Appendix A). The user has the capability of selecting a section and 
seeing the identical output as would appear if the document was printed. Displaying the SRD 
is recommended to quickly review answers, especially during the development phase of 
document preparation. 

If the document has previously been baselined (discussed later in Section 3.21), then a 
menu will appear giving the user the option of displaying the document from the baselined 
version, the current revision, or neither version. If the neither option is chosen, then it is 
assumed that the user does not want the document displayed, and the program will 
automatically return to the previous menu. If the baseline option is chosen, then the 
document will be displayed from the file which is in the project baseline subdirectory. If the 
current revision option is chosen, then the document will be displayed from the version of 
the document which the user is currently revising. If the document has not been baselined, 
then the document will be displayed from the current version. 

Most SRD sections will require multiple page displays. Please note that to view the 
equivalent of an entire printed page, there will be at least three and usually four screen 
displays. Use the Page Up/Page Down method to move up or down in the document. Once 
a page is adequately reviewed, press the SPACE key to retrieve the next page in sequence. 
To abandon a display at any time, press the F10 key. 

3.15 Create an ASCII File of SRD 

The APET software does not have the ability to generate or insert graphics, charts, etc. 
that were created in some other application. This is primarily due to the memory size 
limitations of the computer. However, to alleviate this limitation, APET does have the 
ability to generate an ASCII file of its SRD output. After choosing this option, the user need 
only type in the full file name (includes drive, file name, and extension). The file will then 
be created as a replica of the printed output. 

The benefit of creating an ASCII text file of the SRD is in providing the user with the 
capability of enhancing the final printing by inserting graphics, photos, tables, equations, or 
other difficult to create figures. In addition, different fonts, font sizes, and special effects 
can be used to dress up the final printed output. 
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3.16 Billing Out the ERD 


To fill out the ERD, the user must first select "Project Selection" from the APET Main 
Menu. Upon this action, the Project Selection/Identification Menu (Figure 3) will be 
presented for the user to identify either a new project or select an existing project. Once the 
selection/identification has been made, the SRD/ERD Activity Menu (Figure 4) will be 
presented. Please note that the selected project is shown on the upper right comer of the 
screen. Please be sure that the project shown is the one you wish to work. 

The SRD/ERD Activity Menu presents eleven options for the user. The most significant 
of these is the first: "FILL OUT DOCUMENTATION". The selection of this option will 
present the Fill Out SRD/ERD Documentation Menu (Figure 5). This menu offers the user 
three options: "ENTER PROJECT INITIALIZATION INFORMATION", "COMPLETE 

SCIENCE REQUIREMENTS DOCUMENT (SRD)" and "COMPLETE EXPERIMENT 
REQUIREMENTS DOCUMENT (ERD)". Select "COMPLETE EXPERIMENT 
REQUIREMENTS DOCUMENT (ERD)" if the project initialization information has already 
been entered. If this information has not already been entered, select it before generating the 
ERD. 


3.17 Complete Experiment Requirements Document 

To complete the Experiment Requirements Document, the user must answer a series of 
questions about the experiment. The questions are grouped into topics, a list of which is 
presented to the user. The user is asked to select the topic which is to be displayed. The 
chosen topic will be displayed along with the subtopics covered within that section. The user 
is prompted as to whether or not he wishes to begin or continue filling out the questions in 
that section. (For an outline of the topics to be addressed, see Appendix B.) If the user 
chooses to fill out the section, he will be prompted to select one of the subheadings. Upon 
subheading selection, a brief description of the topic will be given, along with any necessary 
instructions for answering the question. 

If the question invokes the editor, the answers should be given in the form of short 
narratives, consisting of one or more paragraphs of text. Sufficient space will be given to 
write as much (or little) as required. If an answer requires a numeric response, enter the 
number just as you wish it to appear. A sample of this procedure is shown in Figures 7 
through 11. 
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— "Automated Payload Experiment Tool" 

The suggested outline for the Experiment Requirments Document (ERD) 
is as follows. Please choose the section with which you would like to 
begin / resume: 


FI Help 


1.0 Functional Objectives & Equipment Identification 

2.0 Structural / Mechanical 

3.0 Pointing / Stabilization and Alignment 

4.0 Orbital Requirements and Constraints 

5.0 Electrical Requirements 

6.0 Thermal Control / Fluid Requirements 

7.0 Data System Requirements 

8.0 Flight Software Requirements 

9.0 Physical Integration 

10.0 Mission Operations Support 

11.0 Training Objectives 

12.0 Environmental Con tamina tion Data Requirements 
Return to Previous Menu 


F8 DOS 


F10 Quit 


Figure 7 

ERD List of Sections 


— "Automated Payload Experiment Tool" 

r 1.0 Functional Objectives and Equipment Identification - 

1.1 Functional Objectives 

1.2 Equipment Identification 

1.3 Operational Function Flow 

Do you wish to begin / continue filling out this section ? 

YES 

NO 


1 

FI Help 

F8 DOS 

F10 Quit 


Figure 8 

ERD Section Selection 
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[— "Automated Payload Experiment Tool" 


With which subheading do you wish to begin? 


1.1 Functional Objectives 

1 .2 Equipment Identification 

1.3 Operational Function Flow 
Quit 


1 I 

FI Help 

F8 DOS 

F10 Quit 


Figure 9 

ERD Subtopic Selection 


(— "Automated Payload Experiment Tool" 


Functional Objectives and Equipment Identification 

A definition of the experiment objectives and identification 
of the payload element equipment items needed to accomplish these 
objectives are necessary to define the support required from the 
| by the instrument and the Principle Investigator. 


or 


Press SPACE to continue. 


l 

FI Help 
Space Cont. 

F3 Select 
F4 View 

F8 DOS 

Pg 1 of 1 
F10 Quit 


Figure 10 

ERD Topic Narrative 
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— "Automated Payload Experiment Tool" 

— 1.1 Functional Objectives 

Enter the number of Functional Objectives required for this experiment. 
= > 0 


1 i 

FI Help 
Enter Accept 

F8 DOS 

F10 Quit 


Figure 11 

Sample ERD Question 


Upon selection of a topic, if the questions within that chosen topic have already been 
answered, the user will be prompted with a message saying that the section has already been 
completed. The user then has the options of ADDING, EDITING, or DELETING answers, 
or RETURNING to the previous menu. The user should select an option and follow the 
instructions accordingly. If the chosen topic does not have any related subtopics, and the 
user wishes to complete that section, the program will give instructions for answering that 
question, and the APET editor will be invoked as needed. 

Some of the topics have accompanying illustration(s) in order to give the user a better 
understanding of what information is needed. If you wish to view the illustration, simply 
click on, or select, the appropriate phrase. This will cause the screen to momentarily go 
blank, and the illustration will then be presented. After you have viewed the illustration, 
simply press SPACE and the program will return you to your original screen. 

3.18 Determine Current ERD Required Sections 

The APET software package has been included with a feature to allow the user to 
determine which ERD sections, tables, or figures are required based on the answers supplied 
at the time this option is selected. This allows the user to determine at any given time which 
requirements of the ERD have not yet been satisfied. APET does this by looking at selected 
answers already input by the user, and determining if these answers logically imply that an 
additional section is required. For example, if the user has identified that crew involvement 
is required, then the user will be asked if this crew requires training to conduct the 
experiment. If training is required, and that section has not been addressed, then 'Section 
11.0 Training Objectives' is added to the requirements list. 
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This feature of APET also generates a listing of those figures that are required to be 
prepared off-line. These requirements are also based on answers input in previous sessions. 
Since there is no method of logically checking to see if the user has met these requirements, 
the off-line documents referenced may or may not have been completed by the user. 

It is important to note that this option will provide dynamic results. If answers have been 
added or changed since the last session, then the user may see a different list if it can be 
logically determined that additional sections are now required. This provides the user with a 
valuable tool in meeting the ERD requirements. 

3.19 Printing the ERD 

The user has two methods available to generate output from the APET software in regard 
to the ERD. These include printing the document, and displaying the document. The APET 
application was designed to be flexible enough to go to a variety of printers. As with most 
output, the best results will be with the use of a laser printer. If a laser printer is not 
available, the use of a dot-matrix printer will also be acceptable. A variety, although not 
nearly exhaustive, of dot-matrix printers have been tested with the APET software, and all 
have performed well. 

If the document has previously been baselined (discussed later in Section 3.21), then a 
menu will appear giving the user the option of printing the document from the baselined 
version, the current revision, or neither version. If the neither option is chosen, then it is 
assumed that the user does not want the document printed, and the program will 
automatically return to the previous menu. If the baseline option is chosen, then the 
document will be printed from the file which is in the project baseline subdirectory. If the 
current revision option is chosen, then the document will be printed from the version of the 
document which the user is currently revising. If the document has not been baselined, then 
the document will be printed from the current version. 

The printing of the ERD must be accomplished by printing either selected sections or 
tables of the document. An initial page eject will normally (depending on printer type) 
advance a blank sheet of paper before the first sheet is printed. This will be followed by a 
second page advance, then page one of the document will be printed, followed by two, three, 
etc. through the end of the section. 

When a table/chart is created it is listed as a separate item, to print one, simply select the 
name of the table/chart and it will be printed. Because there are often graphics, and more 
complicated tables, etc. that must be inserted within the textual document, no table of 
contents is printed. Because of the limitation of graphics support, it is suggested that all 
externally generated graphic illustrations, tables, etc. be provided in an appendix, with 
appropriate references throughout the document. 
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While the print procedure is active, a message will appear in the lower left of the screen. 
No other activities may take place while the document is printing. In case the printer runs 
out of paper, an error message will appear. Reload paper in the printer and press the 
SPACE key to continue. 

3.20 Displaying the ERD 

The second method of generating ERD output using APET is to display sections of the 
ERD to the screen. The ERD is divided into twelve major sections, some of which may be 
divided into more subsections (see Appendix B). The user has the capability of selecting a 
section and seeing the identical output as would appear if the document was printed. 
Displaying the ERD is recommended to quickly review answers, especially during the 
development phase of document preparation. 

If the document has previously been baselined (discussed later in Section 3.21), then a 
menu will appear giving the user the option of displaying the document from the baselined 
version, the current revision, or neither version. If the neither option is chosen, then it is 
assumed that the user does not want the document displayed, and the program will 
automatically return to the previous menu. If the baseline option is chosen, then the 
document will be displayed from the file which is in the project baseline subdirectory. If the 
current revision option is chosen, then the document will be displayed from the version of 
the document which the user is currently revising. If the document has not been baselined, 
then the document will be displayed from the current version. 

Most ERD sections will require multiple page displays. Please note that to view the 
equivalent of an entire printed page, there will be at least three and usually four screen 
displays. Use the point-and-click (or Page Up/Page Down) method to move up or down in 
the document. Once a page is adequately reviewed, press the SPACE key to retrieve the 
next page in sequence. Displays will continue until all output has been presented. 

3.21 Pi is -dimng a D ocum ent 

At some point in the documentation procedure, the SRD/ERD will be considered 
complete and released to external offices, agencies, organizations, etc. When this occurs, 
that version of the document is considered the baseline, and should be easily identified as 
such. 

To aid in the process of maintaining separate versions of the SRD and ERD, an option 
exists to baseline the current version of the document, (see Figure 12) The selection of this 
option will cause a replica of the current version's answers (or data files) to be copied to a 
new subdirectory for that experiment. This new subdirectory will be called BASELINE. 
From that point, all additional editing will transpire on a new version of the answers, while 
the baselined version of the answers will remain intact. The generation of output will require 
the user to identify which version (baseline or current revision) he wishes to access. 
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Automated Payload Experiment Tool 


At some point in the documentation process, it is necessary to 
declare that all documents are complete, and that any changes 
to be made will be treated as revisions to the baseline document. 

Do you want to baseline your answers at this time? 


YES 

NO 



FI Help 

F8 DOS 

F10 Quit 


Figure 12 
Baseline Menu 

3.22 Comparing a Baseline to the Current Revision 

Once the document has been baselined (see Section 3.21), the user may wish to compare 
this baseline with the current revision. APET provides a mechanism to accomplish this task. 
By selecting the option "Compare Baseline to Current Revision", a DOS routine will be 
invoked to compare all identical data files from the current revision to the baseline document. 
This comparison generates a file that can then be displayed or printed, so that a quick review 
will show which answers have been modified since the original baseline date. 

3.23 Copying An swe r s to Disk 

The final output option provided by APET is the creation of files that contain all data 
generated by the software. This can be used as either a backup mechanism during the 
creation of the files, or as a means of submission of the final document instead of a hard 
copy/printed document. By submitting the answers on diskette, the receiving party can have 
direct access to the answers in the same manner as would the sender. These files are not 
formatted as an ASCII file, and should not be confused with the final report output, which 
can be created using the "Create an ASCII File of SRD" (discussed in Section 3.15). 

The user will have the option of selecting either the baseline document or the current 
revision. After this selection, the user is asked to select the drive to receive the backup 
(either A:,B:,C:, or D:). A DOS copy command will then be invoked to copy all files to the 
selected drive. 
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4.0 HELPFUL HINTS 


1) Avoid the use of the F10 key to exit from within the APET application. It is a better 
practice to "back out" of the APET system through the use of the menus. By doing so, the 
user ensures that all answers are properly recorded to the disk drive. Use of the F10 key 
from within the APET application will allow the user to exit but will not automatically save 
information generated during the session. 

2) APET does not support the insertion of externally generated graphics, tables, 
equations, or other non-text material. To alleviate this problem without the added labor of 
using a secondary word processor, it is suggested that any such material be included in an 
Appendix, and referenced in the text generated in APET. 

3) To insert an externally generated text file into the text area in the APET editor, use 
the command A KR from within the editor. This is one of a variety of commands that can be 
used from the APET word processor. To see all available commands, press the FI key from 
inside the editor and page through the instruction set. 

4) The APET editor uses a word wrap routine that automatically wraps the line to the 
next line (a common word processing feature). It also maintains vertical alignment along the 
left margin. If you use indented paragraphs, please be sure that the line after the indented 
line begins in the column you desire. To do this, use the backspace key to move the first 
word in the line to the column desired. The recommended solution to this problem is not to 
indent paragraphs, but instead insert a blank line between each paragraph. 

5) If your computer system is configured to automatically load WINDOWS or some 
other application package, it may be necessary to alter the AUTOEXEC.BAT file (located in 
the boot drive). Instructions for changing the automatic load of an application will vary by 
computer. One of the easier methods is to edit the AUTOEXEC.BAT file and remove the 
line that calls the package. For example, WINDOWS is called by the command WIN. By 
preventing these packages from loading, a significant amount of RAM is freed and allowed 
for use by APET. 
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APPENDIX A 


SRD Topic Outline 


1.0 INTRODUCTION 

1 . 1 Description of Experiment 

1.2 Scientific Knowledge to be Gained 

1.3 Value of Knowledge to Scientific Field 

1 .4 Justification of the Need for Space Environment 

2.0 BACKGROUND 

2.1 Description of Scientific Field 

2.2 Current Application for Research 

2.3 Brief Historical Account of Prior Research 

2.4 Current Research 

2.5 Relationship of Proposed Experiment 

2.6 Anticipated Advance in State of the Art 

3.0 JUSTIFICATION FOR CONDUCTING THE EXPERIMENT IN SPACE 

3.1 Limitations of Ground-Based Testing 

3.2 Limitations of Drop Towers 

3.3 Limitations of Testing in Aircraft 

3.4 Need for Accommodations in the Shuttle 

3.5 Limitations of Mathematical Modeling 

3.6 Limitations of Other Modeling Approaches 

4.0 EXPERIMENT DETAILS 

4.1 Experiment Procedures to be Used 

4.2 Measurements Required 

4.3 Test Plan Including Ground Characterization of Flight Hardware 

4.4 Specific Analysis Required 

4.5 Preflight Experiment Planned 

4.6 Post Flight Data Handling and Analysis 

4.7 Mathematical Models Used 

4.8 Application of Results 

5.0 EXPERIMENT REQUIREMENTS 

5.1 Experiment Sample Requirements 

5.2 Atmospheric Requirements 

5.2.1 Pressure 

5.2.2 Gas Composition 

5.2.3 Humidity 

5.2.4 Vacuum 

5.3 Temperature Control and Measurement 

5.4 Vibration Control and Measurement 
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5.5 Test Matrix 

5.6 Imaging Requirements 

5.6.1 Photography 

5.6.2 Radiography 

5.6.3 Television 

5.6.4 Resolution 

5.6.5 Frame Rate 

5.7 Electromagnetic Limitations 

5.8 Astronaut Involvement 

5.8.1 Extravehicular Activity 

5.8.2 Activation of Experiment 

5.9 Data Requirements 

5.10 Telepresence and Telerobotics 

5.10.1 Telepresence 

5.10.2 Telerobotics 

6.0 PRINCIPAL INVESTIGATOR'S REQUIREMENTS 

6. 1 Research Equipment 

6.1.1 Preflight 

6.1.2 Post flight 

6.2 Apparatus Design Assistance 

6.3 Consultation 

6.4 Grants and Contracts 

6.4.1 Grants 

6.4.2 Contracts 

6.5 Services 

6.5.1 Film Developing 

6.5.2 Software Development 


7.0 OTHER REQUIREMENTS 


APPENDIX B 


ERD Topic Outline 


1.0 FUNCTIONAL OBJECTIVES AND EQUIPMENT IDENTIFICATION 

1 . 1 Functional Objectives 

Functional Objectives Requirements Sheets 

1.2 Equipment Identification 

Figure 1-1 Instrument Block Diagram (chart) 

Table 1-1 Experiment Functional Objectives (equipment list) 

1.3 Operational Function flow 

Table II- 1 Operational Function Flow (chart) 

2.0 STRUCTURAL / MECHANICAL 
Narrative Description 

Figure 2-1 Structural / Mechanical Sketch(graphics) 

3.0 POINTING / STABILIZATION AND ALIGNMENT 

3.1 Requirements Description(table) 

3.2 Pointing Stabilization and Field-of-View Requirements(table) 

3.3 Experiment Pointing and Field-of-View Capabilities(table) 

3.4 Experiment On-Orbit Acceleration and Vibration Limits(table) 

3.5 Experiment Alignment and Coalignment Requirements(table) 

4.0 ORBITAL REQUIREMENTS AND CONSTRAINTS 
Table 4-1 Desired Orbit Characteristics 

Table 4-2 Earth and Celestial Target List and Viewing Time Requirements 
Table 4-3 Viewing Requirements and Constraints (Earth or Solar) 

Table 4-4 Viewing Requirements and Constraints (Celestial Viewing) 

Table 4-5 Vehicle Motion and g-Level Limits 

5.0 ELECTRICAL REQUIREMENTS 
Narrative Description 

Figure 5-1 Power Profile Per Item of Equipment and Composite(graphics) 

6.0 THERMAL CONTROL/FLUID REQUIREMENTS 

6.1 Heat Transfer Characteristics 

Table 6-1 Module Equipment On-Orbit Thermal Requirements 
Table 6-2 Pallet / Airlock Equipment On-Orbit Thermal Requirements 

6.2 Fluid Requirements 

Table 6-3 Module Equipment On-Orbit Fluid Requirements 
Table 6-3 Pallet / Airlock Equipment On-Orbit Fluid Requirements 
Table 6-3 Module Equipment Ascent / Descent Fluid Requirements 
Table 6-3 Pallet / Airlock Equipment Ascent / Descent Fluid Requirements 
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6.3 Ascent / Descent Thermal Control Requirements 

Table 6-1 Module Equipment Ascent / Descent Thermal Control Requirements 
Table 6-2 Pallet /Airlock Equipment Ascent / Descent Thermal Control Requirements 

7.0 DATA SYSTEM REQUIREMENTS 

7.1 Payload Element to CDMS Interfaces Tables 
Other Systems - Narrative Description 
Table 1 Signal Interface Definition(graphics) 

Table 2 Signal Interface Definition Expansion(graphics) 

Table 3 Display Requirements (graphics) 

Table 4 Event / Exception Monitor Requirements(graphics) 

Table 5 Direct HRM, Analog, Video and MTU Requirements(graphics) 

Table 6 Processed Dedicated HRM Channel Parameter Definition(graphics) 

Table 7 POCC Display Requirements(graphics) 

Table 8 POCC limit Sensing / Exception Monitor Requirements(graphics) 

7.2 Caution and Warning 

Table 1 Signal Interface Definition(graphics) 

7.3 Error Message Documentation 

Figure 7-1 Error Message Input Form(graphics) 

8.0 FLIGHT SOFTWARE REQUIREMENTS 

8.1 Summary of Experiment Computer Software Requirements 
Table 8-1 Experiment Computer Software Requirements Summary 
Functional Description of Software Package(s) 

9.0 PHYSICAL INTEGRATION 

9.1 Physical Integration 

9.1.1 Experiment / Facility Preintegration(graphics) 

9.1.2 Experiment Integration(graphics) 

9.1.3 Payload Integration(graphics) 

9.1.4 Experiment Deintegration(graphics) 

9.2 Experiment / Facility Developer Requirements Definition 

9.2.1 Experiment / Facility Preintegration 

Table 9-1 Experiment / Facility Requirements 

9.2.2 Experiment / Facility Preparation 

Table 9-1 Experiment / Facility Requirements 

9.2.3 Experiment User Room Requirements 
Table 9-1 Experiment / Facility Requirements 

9.2.4 Experiment Late-Access Design Requirements 

9.2.5 Post Mission Requirements 

Table 9-1 Experiment / Facility Requirements 

9.2.6 Post Mission Early- Access Requirements 

Table 9-1.1 Solids, Fluids, and Gases, Resource Requirements 
Table 9-2 Integration of Experiment 
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10.0 MISSION OPERATIONS SUPPORT 

10.1 POCC Requirements 

10.1.1 POCC Processing 

10.1.2 EGSE 

10.1.3 Workstation 

10.1.4 Remote Interfaces 

10.1.5 Other Support Requirements 

10.2 Spacelab Data Processing Facility and Other Data Requirements 

11.0 TRAINING OBJECTIVES 

11.1 PED / PI Defined Training 

11.2 PMM and PED / PI Jointly Defined Tra inin g 

11.3 PMM Defined Training 
Table 11-2 Training Objectives 

11.4 Training Simulators 

11.5 Training Participation 

Table 11-1 Training Participation 

12.0 ENVIRONMENTAL CONTAMINATION DATA REQUIREMENTS 
Table 12-1 Flight Environment Limits 

Table 12-2 On-Orbit External Contamination Control Sensitivity 
Table 12-3 External Contamination Sources 
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APPENDIX C 


APET Editor Commands 


MOVING THE CURSOR: 


A D Left One Character 

A S Right One Character 

A A Left One Word 

A F Right One Word 

"I Tab 

A E Up One Line 

A X Down One Line 

A W Scroll Up 

A Z Scroll Down 

A R Page Up 

A C Page Down 

A QS Beginning of a Line 

A QD End of a Line 

A QE Beginning of a Page 

A QX End of a Page 

A QR Beginning of a File 

A QC End of the File 

A QB Beginning of Marked Block 

A QK End of Marked Block 


DELETING AND INSERTING TEXT: 

A G 

A H 

A Y 

A QY 

A KY 

A V 

A N 

BLOCK COMMANDS: 


A KS Save This File 

A KB Mark Beginning of Block 

A KK Mark End of Block 

A KH Hide / Display Block 

A KC Copy a Block 

A KV Move a Block 

A KY Delete a Block 

A KR Read a Block from a File 

A KW Write a Block to a File 

A KP Print a Block or File 


Delete Character Under Cursor 
Delete Character Left of Cursor 
Delete Next Word 
Delete a Line 

Delete to the End of a Line 
Delete a Marked Block 
Insert On/Off 
Insert a Line 
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FORMATTING COMMANDS: 


A B Reformat Paragraph 

A OR Set Right Margin 

A QI Toggle Auto indent Mode 

A QW Toggle Word Wrap 


FIND AND REPLACE COMMANDS: 


^QA Find and Replace a String 

^QF Find an Occurrence of a String 

~L Find the Next Occurrence 
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For assistance in using this software, 
or to offer suggestions or comments, 
please contact the following: 

Mr. Gary Maddux 
Ms. Anna Provancha 
Mr. David Chattam 

at (205) 895-6343, 
or write 

Systems Management and Production Laboratory 
Research Institute 
RI E-47 

The University of Alabama in Huntsville 
Huntsville, AL 35899 
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1.0 INTRODUCTION 


So you want to fly an experiment on the Shuttle. 

Well, to begin the process, we must get a little information about your experiment and its 
requirements. 

If you have flown with us in the past, you may remember a substantial amount of paper 
documentation was required. This application, the Automated Payload Experiment Tool, is 
designed to alleviate much of the burden of the document preparation and maintenance 
process. This system can currently be used to prepare three support documents: the Science 
Requirements Document (SRD), which defines the science objectives, the Experiment 
Requirements Document (ERD), which defines the experiment design/build requirements and 
the Project Plan. The version that you have is for the creation of the Project Plan only. 


2.0 DISCUSSION 

2.1 Background 

The Microgravity Experiment Projects (MEP) Office of the Payload Projects Office 
(PPO) at the Marshall Space Flight Center (MSFC) is currently responsible for collecting and 
coordinating experiment/facility specifications and requirements between NASA and various 
colleges, universities, research centers, and other public- and private-sector organizations 
that are selected or are requesting to fly their respective microgravity experiments on 
designated flights. This coordination involves the communication of flight hardware 

requirements and the preparation and review of all documentation between NASA and the 
research groups. To reduce difficulties encountered by these customers of NASA, an effort 
was undertaken to research, analyze, and evaluate the current procedures involved in the 
information gathering activities. 

The MEP Office identified a need to develop an Automated Payload Experiment Tool 
(APET) which would lead experiment developers through the development planning process, 
obtain necessary information, establish an electronic data exchange avenue and allow easy 
manipulation/reformatting of the collected information. In order to fulfill this need, the 
University of Alabama in Huntsville (UAH) was tasked to design and develop the APET 
software package to meet the increasing demands to lighten the burden of documentation 
preparation and maintenance for NASA and its customers. 

2.2 System Requirements 

The objective of APET is to provide an easy to use tool to the Principal Investigator (PI) 
team. To ensure ease of use, few computer hardware requirements are necessary to operate 
the APET software package. 


APET is designed to run on any EBM-PC compatible personal computer. It is 
recommended that the APET user install the software on a 286 PC or higher. The multiple 
screen windows, and the complexity of the system cause noticeable slowdowns on any 
machine less than the 286. 

The software requires that the PC be equipped with a hard disk drive. For proper 
execution, the hard drive (or some partition of it) must be named C:. The Project Plan 
version of APET will require approximately 2M (megabytes) of space on the hard drive for 
the system, plus another 1M on the hard drive for the data files created by the user. 
However, for optimal performance, the hard drive should have a total of at least 4M free 
upon installation of the software. 

For ease of use, the PC should be equipped with a mouse. This, however, is not 
mandatory. APET utilizes the hypertext technology, which offers a point-and-click user 
interface. Instead of a mouse, the user does have the option of pressing selected function 
keys to achieve the same effect. 

2.3 Installation 

The APET software package is provided on one 3 1/2" high density diskette. The files 
stored on this diskette have been compressed; therefore, it is required that the user follow 
several simple steps to ensure correct installation. 

1) Insert the 3 1/2 " diskette in the drive designated as A:. If the A: drive on your 
system is not the correct size, then use the DOS ASSIGN command to redesignate the drives 
appropriately. (For example, if you have 3 1/2" disks but your 3 1/2" drive is B:, then at 
the DOS prompt type ASSIGN A: B:.) 

2) From this drive (A:) type: 

PINSTALL. 

This will activate the installation routine. A series of instructions and informational text 
will be presented. Each screen will advise what is transpiring in the installation procedure. 
The installation routine will create a subdirectory on the C: drive called GARDEN. Once 
created, the files contained on the installation disks will be copied to the directory 
C:\GARDEN. Most of these files have been compressed to conserve disk space. An 
uncompress routine will be invoked to return these files to their normal (and usable) 
condition. To cancel the installation at any time, press the CTRL (control) C keys. 

3) Upon successful installation of the APET program files, the message 
INSTALLATION ROUTINE COMPLETE will be displayed. The APET application, 
running under the direction of Knowledge Pro software, will be entered and you will be 
presented the opening menu. All subsequent sessions using the APET software may be 
initiated by going to the C:\GARDEN subdirectory and typing PLAN. 
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2.4 Getting Started 


This application uses hypertext technology. Hypertext software systems allow for the 
retrieval of related information at the point and click of a mouse or, if a mouse is not used, at 
the touch of one or two keystrokes. For information on a highlighted topic, just move the 
mouse to that word and click. A window will be opened, overlaying the current window. In 
the new window, the information will immediately be displayed. Once this support 
information has been reviewed, press SPACE (or ESC) once to close the window and return 
to your original screen. If you are not using a mouse, please use the F3 and F4 function 
keys (marked Select and View) as indicated at the bottom of the screen, (see Figure 1). The 
F3 key allows you to select the different hypertext topics. Once the desired topic is selected 
(i.e. highlighted), the F4 key calls the background information for view. 

Multiple page displays are indicated by the Pg 1 of 2 message at the lower right of the 
screen. To navigate through multiple screen displays, please use the Page Up and Page 
Down keys to scroll either forward or backward through the pages. 


"Automated Payload Experiment Tool" 

So you want to fly on the Shuttle. 

Well before you can, we must get a little information about 
your experiment and its objectives. 

If you have flown with us in the past, you may remember a substantial 
amount of paper documentation was r equired. This application, the 

is designed to alleviate much 

of the burden of the preparation process by utilizing 

knowledge-based system. This system can currently be used to prepare 
two of our support documents, the Science Requirements Document (SRD), which 
defines the science objectives and the Experiment Requirements Document (ERD), 
which defines the experiment design/build requirements. 

Press SPACE to continue. 


FI Help 

F3 Select 


Pg 1 of 1 

Space Cont. 

F4 View 

F8 DOS 

F10 Quit 


Figure 1 

Sample Screen Layout Using Hypertext 


For help at anytime throughout the APET application, press the FI key. This will 
retrieve location sensitive help information, and may be called from the system or system- 
called edit screens. This will be the method by which assistance information will be 
retrieved throughout this application. 
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APET has been designed as a menu-driven software package. This means that any 
function required of the user can be activated via a menu option. This includes exiting the 
system. It is strongly recommended that the user always "back out" of the application by 
using the appropriate menu options, i.e. "Return to Previous Menu". An option does exist to 
exit from any point in the application by selecting F10. It is not recommended that this be 
used from inside a question/answer section of the application. The F10 command causes an 
immediate exit from the program, without checking to ensure that open files have been 
properly saved. Therefore, the user may experience data loss if the application is exited in 
this manner. 

After the installation and initial use of the APET software, future sessions will be 
initiated by going to the C:\GARDEN subdirectory and typing PLAN. This will activate the 
software and present the opening menu, (see Figure 2). 


i — "Automated Payload Experiment Tool" 


Please select the activity of your choice, or choose Exit 
to leave the system. 


How to use the System 
Project Selection 
Project Plan (Overview) 
Glossary/Acronyms 
Print Glossary/ Acronyms 
Exit System 





FI Help 




F8 DOS 

F10 Quit 


Figure 2 

Opening APET Main Menu 

Due to the hypertext capabilities of the APET software, a large amount of RAM (random 
access memory) is required. Because of the heavy RAM demand, proper execution of the 
software requires no other software package be running simultaneously with the APET 
software. Whenever the available RAM becomes too little for the application, an 
"Insufficient Memory" message will be shown at the bottom right of the screen. To alleviate 
this situation, simply get out of APET and reboot the system. This will usually free up all 
available RAM and ensure proper execution, (see Helpful Hints for further instruction.) 
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3.0 USING THE APET SYSTEM 


3.1 How to Use the System 

Because the use of a hypertext tool may be a new experience, a brief on-line tutorial is 
provided with APET. To use this tool, please choose option one on the opening menu 
entitled "How to Use the System" . To select this option, point with the mouse to the phrase 
and click. If not using a mouse, use the arrow keys to highlight the option and press 
RETURN. You can tell when an option has been selected because it (the phrase or word) 
will be highlighted differently from all other options. As the mouse is moved to other 
options, each in turn will be highlighted. 

Once the "How to Use the System" option has been selected, a different screen will be 
presented with a brief overview of hypertext and the methods of selecting topics. (This 
overview is much the same as appears in Section 2.4 of this users guide.) Practice selecting 
topics and moving from one screen to another using either the mouse or the appropriate 
keyboard function keys. 

3.2 Project Selection 

The APET software package will accommodate one or more experiments for the user. 
However, each experiment must be identified by a short (8 characters or less) name, which 
must conform to the naming convention used by the DOS computer operating system. 
Briefly, these rules state that a DOS name cannot be over 8 characters in length, and must 
contain a combination of either letters, numbers, or the underscore (_) character. Any other 
special keys, including the SPACE, are prohibited. The rationale behind this naming 
convention is to allow storage of data files for each experiment in a subdirectory for that 
specific experiment. For example, if a user is working on two experiments, identified as 
THINFILM and HIPROTEN, then there would be a subdirectory for each. The 
configuration of these files would be as follows: 


Root Directory Application Directory Exp erime n t D irect ory 

C:\ GARDEN\ THINFILM 

HIPROTEN 


Therefore, all data files containing answers for the APET questions for the experiment 
THINFILM would appear in the subdirectory THINFILM. If additional experiments are 
required, the user would identify the new experiment and an additional subdirectory would 
be added. 
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Figure 3 shows the menu for selecting, adding, or deleting an experiment project. In the 
example, the experiment AADSF_L has been previously defined by the user. If the user 
wants to work on this experiment, he simply points and clicks on this selection. (This would 
be the case in a majority of the cases, since most Principal Investigators will have only one 
active experiment at any given point). However, if another experiment is required, the user 
would click on "ENTER A NEW PROJECT". The user would be prompted to identify the 
new experiment, and would immediately be passed into the APET system, where information 
regarding that experiment would be addressed. 

r— "Automated Payload Experiment Tool" 1 


Please select the project of your choice, or enter a new 
project. 


AADSFJL 

ENTER A NEW PROJECT 
DELETE AN OLD PROJECT 
RETURN TO MAIN MENU 


1 

FI Help 

F8 DOS 

F10 Quit 


Figure 3 

Project Selection/Identification Menu 


If a user wishes to delete an experiment, along with all its associated data files, he may 
do so by selecting the "DELETE AN OLD PROJECT" option from the menu. However, 
there is no recoverable procedure to undelete a project. Therefore, the user is strongly 
advised to use this procedure with caution. 

3.3 Project Plan Overview 

The third selection from the APET Main Menu is the "Project Plan Overview". This 
option should be selected when the user wishes to see an overview of the Project Plan 
document, along with brief explanations of the information to be covered in each 
section/subsection of the document. For an additional overview of the topics to be addressed 
in the Project Plan, see Appendix A of this document. 
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3.4 Glossary / Acronyms 

A number of NASA specific terms, definitions, and acronyms will appear as support 
material throughout the documentation process. One of the primary advantages of using a 
hypertext-based tool is to allow for easy and immediate retrieval of these terms. 

Option number four from the APET Main Menu allows the user to retrieve a listing of 
these terms, and presents them in a form analogous to a glossary in a book. To view a 
definition, highlight the desired term and click. A term can be highlighted by using the 
mouse to move the cursor to that word, or by using the F3 key for selection. To view the 
definition, the user should either click the mouse or press the F4 key. The definition of that 
word/term will be presented. Should the definition contain a term that requires further 
description, highlight that word and click. The new definition will overlay the previous 
definition. This method can be repeated as long as further definitions exist and the memory 
capacity of the machine is not exceeded. 

Please note that the glossary consists of multiple pages. Remember to navigate through 
the multi-page displays by using either the Page Up/Page Down function keys. 


3.5 Print Glossary/ Acronyms 

Option number five from the APET Main Menu activates a routine for the printing of the 
glossary/acronym list, as discussed in Section 3.4. Because the output of this selection will 
be a multi-page document, the use of this option will be rare. 


3.6 Filling Out the Project Plan 

To fill out the Project Plan, the user must first select "Project Selection" from the APET 
Main Menu. Then the Project Selection/Identification Menu (Figure 3) will be presented for 
the user to identify either a new project or select an existing project. Once the 
selection/identification has been made, the Project Plan Activity Menu (Figure 4) will be 
presented. Please note that the selected project is shown on the upper right comer of the 
screen. Please be sure that the project shown is the one you wish to work. 
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Automated Payload Experiment Tool 


The project you have selected is: AADSF_L 
Please enter your choice of activities from the list. 

FILL OUT DOCUMENTATION 

PRINT PROJECT PLAN 

DISPLAY PROJECT PLAN 

DETERMINE IF PROJECT PLAN IS COMPLETE 

BASELINE DOCUMENT 

COMPARE BASELINE TO CURRENT REVISION 

COPY ANSWERS TO DISK 

RETURN TO PREVIOUS MENU 

RETURN TO MAIN MENU 

QUIT 


. . 

FI Help 

F8 DOS 

F10 Quit 


Figure 4 

Project Plan Activity Menu 

The Project Plan Activity Menu presents ten options for the user. The most significant of 
these is the first: "FILL OUT DOCUMENTATION". The selection of this option will 
present the Fill Out Project Plan Documentation Menu (Figure 5). This menu offers the user 
two options: "ENTER PROJECT INITIALIZATION INFORMATION", and "COMPLETE 
PROJECT PLAN." 

r— "Automated Payload Experiment Tool" 1 


Please select the activity you wish to perform on 
the ADDSF L project. 


Enter Project Initialization Information 

Complete Project Plan 

Return to Previous Menu 

Return to Main Menu 

Exit System 


FI Help 




F8 DOS 

F10 Quit 


Figure 5 

Fill Out Project Plan Documentation Menu 
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3.7 Entering Project Initialization Information 

Under most circumstances, the first information entered by the user into the APET 
system is the project initialization information. To enter this information, select option one 
from the Fill Out Project Plan Documentation Menu. This information is used to identify 
certain aspects of the experiment, and will be used throughout the documentation process. 
Entries include the PI name, organization, address, city, state, zip, phone, and experiment 
title. This information will be provided in the form of type written responses to user 
prompts. For example, the user will be asked: 


Please enter your first and last names, i.e. Dr. John Doe. 


The user should respond with a one line response. (If there is a limitation on the length 
of this one line response, the screen display will provide an instruction, such as "Please l imi t 
your response to 16 characters.") This will be the format of user entries throughout the 
APET application. When the user is prompted to make an entry, the response should be on 
one line. When the user responds with a RETURN, the answer is stored and the next 
question, if one exists, is asked. Once all questions for that segment have been answered, 
the answers are written to a data file. 

In the "Project Initialization Information" subsection, the only variation in the user 
prompt/one line response routine is with the experiment title. Because experiment titles can 
be several lines, the user is given a prompt and immediately sent to the APET editor. This 
editor is a small version of a word processor, with many of the functions of a common word 
processing package. The commands used in the APET editor are similar to those in the 
software package WORDSTAR. To see the commands available, press the FI function key 
from inside the editor. A separate window will be opened and will overlay the current 
screen. From there, page down until the function you wish to perform is shown. The one- 
to-two keystroke command to accomplish the task will be shown. (Note: The symbol C) 
represents the CONTROL key, i.e. A KQ means to hold the CONTROL key down while 
pressing the letter K, then press the letter Q.) When the user is finished entering the answer 
into the editor, he may exit by pressing the ESC (escape) key. A message will then appear 
on the screen that tells the user what file name is being saved. Respond with a RETURN to 
accept this name and save the answer, or an ESC to cancel the answer. 

Important: Do not change the file name when the APET software asks if the name is 
acceptable. Future sessions that allow the user to change, delete, print, or display the Project 
Plan answers require that these file names be used. Changing the file name will make the 
file either inaccessible or inappropriate. Therefore, always accept the file name as given. 
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3.8 Complete Project Plan 


To complete the Project Plan Document, the user must answer a series of questions about 
the experiment. (For an outline of the topics to be addressed, see Appendix A.) A sample 
question from the Project Plan is shown in Figure 6. 


- 4.0 Content 

— 4.1 Introduction 

Please describe the relevance of the investigation and provide 
a summary rationale as to why a flight experiment is required 
(limit your answer to one printed page). 

Press the RETURN KEY to enter the editor, 

ESC to leave the editor, and RETURN to confirm save. 
C:\GARDEN\AADSF_L\PPE4_1.DAT 

THIS IS WHERE YOUR ANSWER GOES . 


FI Help 


Pg 1 of 1 

Space Cont. 

F8 DOS 

F10 Quit 


Figure 6 

Sample Project Plan Question Screen 


The questions are grouped into topics, a list of which is presented to the user. The user 
is asked to select the topic which is to be addressed. The chosen topic will be displayed, 
along with either its accompanying question or the subtopics covered within that section. If 
the user chooses to fill out one of the subsections, he will be prompted to select from a list. 
Upon subheading selection, a brief prompt, along with any necessary instructions for 
answering the question will be displayed. 

Each question in the Project Plan will invoke the editor. Answers should be given in the 
form of short narratives, consisting of one or more paragraphs of text. Sufficient space will 
be given to write as much (or as little) as required. A sample of this procedure is shown in 
Figures 7 through 10. 
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— "Automated Payload Experiment Tool" 

r~ Complete Project Plan 

Which section do you wish to address? 


1 .0 General 

2.0 Preparation and Approval 

3.0 Changes 

4.0 Content 

Return to Previous Menu 



FI Help 

F8 DOS 

F10 Quit 


Figure 7 

Project Plan List of Sections 


— "Automated Payload Experiment Tool" 

r~ 4.0 Content 

Which section would you like to complete? 


Introduction 

Objectives 

Science Requirements 
Technical Plan 
Implementation Plan 
Management Plan 
Schedule 

Cost Control Plan 

Project Reviews and Meetings 

Return to Previous Menu 


FI Help 


F8 DOS F10 Quit 


Figure 8 

Project Plan Section Selection 
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Automated Payload Experiment Tool 


— 4.4 Technical Plan 

The outline for the Technical Plan includes the following subsections: 


Experiment Hardware Description 
Payload Classification 
Development Approach 
Technology Plan 
Logistics 

Mission Operations, Training and Data Management 

Analysis of Mission Results 

Facilities 

Safety 

Return to Previous Menu 



FI Help 

F8 DOS 

F10 Quit 


Figure 9 

Project Plan Subtopic Selection 


— "Automated Payload Experiment Tool" 

— Mission Operations, Training and Data Management 

Describe the operations approach, starting with a summary of the experiment 
operations sequence, and relate the crew involvement with the operations. Identify 
the location of the integration and operations activities and the organization 
supplying the support and define the level of support required. Identify where and 
how operations training will be performed and how data will be made available to 
the principal investigator for analysis. All assumptions should be clearly stated. 

Press RETURN to enter the editor. Esc to leave the editor, and 
RETURN to confirm save. 


1 

FI Help 

F8 DOS 

F10 Quit 


Figure 10 

Project Plan Topic Narrative 
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Some of the topics have accompanying illustration(s) in order to give the user a better 
understanding of what information is needed. If you wish to view the illustration, simply 
click on, or select, the appropriate phrase. This will cause the screen to momentarily go 
blank, and the illustration will then be presented. After you have viewed the illustration, 
press SPACE and the program will return you to your original screen. 

3.9 Printing the Eroject Han 

The user has two methods available to generate output from the APET software. These 
include printing the document, or displaying the document to the screen. The APET 
application was designed to be flexible enough to go to a variety of printers. As with most 
output, the best results will be with the use of a laser printer. If a laser printer is not 
available, the use of a dot-matrix printer will also be acceptable. A variety, although not 
nearly exhaustive, of dot-matrix printers have been tested with the APET software, and all 
have performed well. 

If the document has previously been baselined (discussed later in Section 3.12), then a 
menu will appear giving the user the option of printing the document from the baselined 
version, the current revision, or neither version. If the neither option is chosen, then it is 
assumed that the user does not want the document printed, and the program will 
automatically return to the previous menu. If the baseline option is chosen, then the 
document will be printed from the file which is in the project baseline subdirectory. If the 
current revision option is chosen, then the document will be printed from the version of the 
document which the user is currently revising. If the document has not been baselined, then 
the document will be printed from the current version. 

The printing of the Project Plan can be accomplished in either of two methods. First, the 
user may choose the section to be printed. This is recommended for a document that is in 
the development process. Once the entire Project Plan has been completed, the user can 
generate the document in its entirety. An initial page eject will normally (depending on 
printer type) advance a blank sheet of paper before the cover sheet is printed. This will be 
followed by a second page advance, then page one of the document will be printed, followed 
by two, three, etc. through the end of the document. Because there are often graphics, 
tables, etc. that must be inserted within the textual document, no table of contents is printed. 
Because of the limitation of graphics support, it is suggested that all externally generated 
graphic illustrations, tables, etc. be provided in an appendix, with appropriate references 
throughout the document. 

While the print procedure is active, a message will appear in the lower left of the screen. 
No other activities may take place while the document is printing. In case the printer runs 
out of paper, an error message will appear. Reload paper in the printer and press the 
SPACE key to continue. 


13 


3.10 Displaying Hie Project Elan 


The second method of generating output using APET is to display sections of the Project 
Plan to the screen. The Project Plan is divided into four major sections, with each divided 
into subsections as necessary (see Appendix A). The user has the capability of selecting a 
section and seeing the identical output as would appear if the document was printed. 
Displaying the Project Plan is recommended to quickly review answers, especially during the 
development phase of document preparation. 

If the document has previously been baselined (discussed later in Section 3.12), then a 
menu will appear giving the user the option of displaying the document from the baselined 
version, the current revision, or neither version. If the neither option is chosen, then it is 
assumed that the user does not want the document displayed, and the program will 
automatically return to the previous menu. If the baseline option is chosen, then the 
document will be displayed from the file which is in the project baseline subdirectory. If the 
current revision option is chosen, then the document will be displayed from the version of 
the document which the user is currently revising. If the document has not been baselined, 
then the document will be displayed from the current version. 

Most Project Plan sections will require multiple page displays. Please note that to view 
the equivalent of an entire printed page, there will be at least three and usually four screen 
displays. Use the Page Up/Page Down method to move up or down in the document. Once 
a page is adequately reviewed, press the SPACE key to retrieve the next page in sequence. 
To abandon a display at any time, press the F10 key. 

3.11 Determining if the Project Plan is Complete 

To aid in the logical completion of the Project Plan, APET provides the user with the 
ability of "Determining if the Project Plan is Complete". By selecting this option, the user 
activates a routine that checks for the existence of the data files created as answers to the 
Project Plan questions. The missing data files are analyzed to determine which sections have 
not been answered, and a listing is displayed to the screen. 

3.12 B a selining a Doc u ment 

At some point in the documentation procedure, the Project Plan will be considered 
complete and released to external offices, agencies, organizations, etc. When this occurs, 
that version of the document is considered the baseline, and should be easily identified as 
such. 

To aid in the process of maintaining separate versions of the Project Plan, an option 
exists to baseline the current version of the document, (see Figure 11) The selection of this 
option will cause a replica of the current version's answers (or data files) to be copied to a 
new subdirectory for that experiment. This new subdirectory will be called BASELINE. 
From that point, all additional editing will transpire on a new version of the answers, while 
the baselined version of the answers will remain intact. The generation of output will require 
the user to identify which version (baseline or current revision) he wishes to access. 
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Automated Payload Experiment Tool 


At some point in the documentation process, it is necessary to 
declare that all documents are complete, and that any changes 
to be made will be treated as revisions to the baseline document. 

Do you want to baseline your answers at this time? 


YES 

NO 


1 

FI Help 

F8 DOS 

F10 Quit 


Figure 11 
Baseline Menu 


3.13 Comparing a Baseline to the Current Revision 

Once the document has been baselined (see Section 3.12), the user may wish to compare 
this baseline with the current revision. APET provides a mechanism to accomplish this task. 
By selecting the option "Compare Baseline to Current Revision", a DOS routine will be 
invoked to compare all identical data files from the current revision to the baseline document. 
This comparison generates a file that can then be displayed or printed, so that a quick review 
will show which answers have been modified since the original baseline date. 

3.14 Copying Answe rs to Disk 

The final output option provided by APET is the creation of files that contain all data 
generated by the software. This can be used as either a backup mechanism during the 
creation of the files, or as a means of submission of the final document instead of a hard 
copy /printed document. By submitting the answers on diskette, the receiving party can have 
direct access to the answers in the same manner as would the sender. These files are not 
formatted, and should not be confused with the final report output. 

The user will have the option of selecting either the baseline document or the current 
revision. After this selection, the user is asked to select the drive to receive the backup 
(either A:,B:,C:, or D:). A DOS copy command will then be invoked to copy all files to the 
selected drive. 
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4.0 HELPFUL HINTS 


1) Avoid the use of the F10 key to exit from within the APET application. It is a better 
practice to "back out" of the APET system through the use of the menus. By doing so, the 
user ensures that all answers are properly recorded to the disk drive. Use of the F10 key 
from within the APET application will allow the user to exit but will not automatically save 
information generated during the session. 

2) APET does not support the insertion of externally generated graphics, tables, 
equations, or other non-text material. To alleviate this problem without the added labor of 
using a secondary word processor, it is suggested that any such material be included in an 
Appendix, and referenced in the text generated in APET. 

3) To insert an externally generated text file into the text area in the APET editor, use 
the command A KR from within the editor. This is one of a variety of commands that can be 
used from the APET word processor. To see all available commands, press the FI key from 
inside the editor and page through the instruction set. 

4) The APET editor uses a word wrap routine that automatically wraps the line to the 
next line (a common word processing feature). It also maintains vertical alignment along the 
left margin. If you use indented paragraphs, please be sure that the line after the indented 
line begins in the column you desire. To do this, use the backspace key to move the first 
word in the line to the column desired. The recommended solution to this problem is not to 
indent paragraphs, but instead insert a blank line between each paragraph. 

5) If your computer system is configured to automatically load WINDOWS or some 
other application package, it may be necessary to alter the AUTOEXEC.BAT file (located in 
the boot drive). Instructions for changing the automatic load of an application will vary by 
computer. One of the easier methods is to edit the AUTOEXEC.BAT file and remove the 
line that calls the package. For example, WINDOWS is called by the command WIN. By 
preventing these packages from loading, a significant amount of RAM is freed and allowed 
for use by APET. 
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APPENDIX A 


1.0 INTRODUCTION 

2.0 PREPARATION AND APPROVAL 

3.0 CHANGES 

4.0 CONTENT 

4.1 Introduction 

4.2 Objectives 

4.3 Science Requirements 

4.4 Technical Plan 

4.4.1 Experiment Hardware Description 

4.4.2 Payload Classification 

4.4.3 Development Approach 

4.4.4 Technology Plan 

4.4.5 Logistics 

4.4.6 Mission Operations, Training and Data Management 

4.4.7 Analysis of Mission Results 

4.4.8 Facilities 

4.4.9 Safety 

4.5 Implementation Plan 

4.5.1 Implementation Approach 

4.5.2 Summary Work Breakdown Structure 

4.5.3 Documentation 

4.6 Management Plan 

4.6.1 Project Management Responsibilities and Organization 

4.6.2 Mission Management Responsibilities and Organization 

4.7 Schedule 

4.8 Cost Control Plan 

4.8.1 Resources 

4.8.2 Cost Control Guidelines 

4.8.3 Cost Reporting and Control Structure 

4.8.3. 1 NASA Reports 

4 . 8 . 3 . 2 Contractor Reports 

4.8.4 Cost Control Strategy 

4.9 Project Reviews and Meetings 

4.9.1 Internal Reviews 

4.9.2 External Reviews 

4.9.3 Design and Readiness Reviews 
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APPENDIX B 


APET Editor Commands 


MOVING THE CURSOR: 


A D Left One Character 

Right One Character 

A A Left One Word 

Right One Word 

A I Tab 

A E Up One Line 

Down One Line 

~W Scroll Up 

Scroll Down 

A R Page Up 

A C Page Down 

A QS Beginning of a Line 

^QD End of a Line 

A QE Beginning of a Page 

A QX End of a Page 

A QR Beginning of a File 

^QC End of the File 

A QB Beginning of Marked Block 

A QK End of Marked Block 


DELETING AND INSERTING TEXT: 

"G 

"H 

Arp 

"Y 

"QY 

A KY 

"V 

A N 

BLOCK COMMANDS: 


~KS Save This File 

~KB Mark Beginning of Block 

A KK Mark End of Block 

"KH Hide / Display Block 

A KC ..Copy a Block 

*KV Move a Block 

A KY Delete a Block 

A KR Read a Block from a File 

*KW Write a Block to a File 

~KP Print a Block or File 


Delete Character Under Cursor 
Delete Character Left of Cursor 
Delete Next Word 
Delete a Line 

Delete to the End of a Line 
Delete a Marked Block 
Insert On/Off 
Insert a Line 


PAGE BLANK NOT FILMED 


FORMATTING COMMANDS: 


Reformat Paragraph 

A OR Set Right Margin 

^QI Toggle Auto indent Mode 

^QW Toggle Word Wrap 


FIND AND REPLACE COMMANDS: 


^QA Find and Replace a String 

~QF Find an Occurrence of a String 

Find the Next Occurrence 
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For assistance in using this software, 
or to offer suggestions or comments, 
please contact the following: 

Mr. Gary Maddux 
Ms. Anna Provancha 
Mr. David Chattam 

at (205) 895-6343, 
or write 

Systems Management and Production Laboratory 
Research Institute 
RIE-47 

The University of Alabama in Huntsville 
Huntsville, AL 35899 
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1.0 INTRODUCTION 


So you want to fly an experiment on the Shuttle. 

Well, to begin the process, we must get a little information about your experiment and its 
requirements. 

If you have flown with us in the past, you may remember a substantial amount of paper 
documentation was required. This application, the Automated Payload Experiment Tool, is 
designed to alleviate much of the burden of the document preparation and maintenance 
process. T his system can currently be used to prepare four support documents, the Science 
Requirements Document (SRD), which defines the science objectives, and the Experiment 
Requirements Document (ERD), which defines the experiment design/build requirements, the 
Project Plan, which is the basic planning document that describes the overall plan for 
proceeding with the project, and the Science Requirements Envelope Document. The version 
that you have is for the creation of the Science Requirements Envelope Document only. 

2.0 DISCUSSION 

2.1 Background 

The Microgravity Experiment Projects (MEP) Office of the Payload Projects Office 
(PPO) at the Marshall Space Flight Center (MSFC) is currently responsible for collecting and 
coordinating experiment/facility specifications and requirements between NASA and various 
colleges, universities, research centers, and other public- and private-sector organizations 
that are selected or are requesting to fly their respective microgravity experiments on 
designated flights. This coordination involves the communication of flight hardware 
requirements and the preparation and review of all documentation between NASA and the 
research groups. To reduce difficulties encountered by these customers of NASA, an effort 
was undertaken to research, analyze, and evaluate the current procedures involved in the 
information gathering activities. 

The MEP Office identified a need to develop an Automated Payload Experiment Tool 
(APET) which would lead experiment developers through the development planning process, 
obtain necessary information, establish an electronic data exchange avenue and allow easy 
manipulation/reformatting of the collected information. In order to fulfill this need, the 
University of Alabama in Huntsville (UAH) was tasked to design and develop the APET 
software package to meet the increasing demands to lighten the burden of documentation 
preparation and maintenance for NASA and its customers. 

2.2 S System Regmiemeife 

The objective of APET is to provide an easy to use tool to the Principal Investigator (PI) 
team. To ensure ease of use, few computer hardware requirements are necessary to operate 
the APET software package. 
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APET is designed to run on any EBM-PC compatible personal computer. It is 
recommended that the APET user install the software on a 286 PC or higher. The multiple 
screen windows, and the complexity of the system cause noticeable slowdowns on any 
machine less than the 286. 

The software requires that the PC be equipped with a hard disk drive. For proper 
execution, the hard drive (or some partition of it) must be named C:. The SRD version of 
APET will require approximately 1M (megabytes) of space on the hard drive for the system, 
plus another 1M on the hard drive for the data files created by the user. However, for 
optimal performance, the hard drive should have a total of at least 3M free upon installation 
of the software. 

For ease of use, the PC should be equipped with a mouse. This, however, is not 
mandatory. APET utilizes the hypertext technology, which offers a point-and-click user 
interface. Instead of a mouse, the user does have the option of pressing selected function 
keys to achieve the same effect. 

2.3 Installation 

The APET software package is provided on one 3 1/2" diskette. The files stored on this 
diskette have been compressed; therefore, it is required that the user follow several simple 
steps to ensure correct installation. 

1) Insert the 3 1/2 " diskette in the drive designated as A:. If the A: drive on your 
system is not the correct size, then use the DOS ASSIGN command to redesignate the drives 
appropriately. (For example, if you have 3 1/2" disks but your 3 1/2" drive is B:, then at 
the DOS prompt type ASSIGN A: B:.) 

2) From this drive (A:) type: 

VINSTALL. 

This will activate the installation routine. A series of instructions and informational text 
will be presented. Each screen will advise what is transpiring in the installation procedure. 
The installation routine will create a subdirectory on the C: drive called GARDEN. Once 
created, the files contained on the installation disks will be copied to the directory 
C:\GARDEN. Most of these files have been compressed to conserve disk space. An 
uncompress routine will be invoked to return these files to their normal (and usable) 
condition. To cancel the installation at any time, press the CTRL (control) C keys. 

3) Upon successful installation of the APET program files, the message 
INSTALLATION ROUTINE COMPLETE will be displayed. The APET application, 
running under the direction of Knowledge Pro software, will be entered and you will be 
presented the opening menu. All subsequent sessions using the APET software may be 
initiated by going to the C:\GARDEN subdirectory and typing ENVELOPE. 
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2.4 Getting Started 


This application uses hypertext technology. Hypertext software systems allow for the 
retrieval of related information at the point and click of a mouse or, if a mouse is not used, at 
the touch of one or two keystrokes. For information on a highlighted topic, just move the 
mouse to that word and click. A window will be opened, overlaying the current window. In 
the new window, the information will immediately be displayed. Once this support 
information has been reviewed, press SPACE (or ESC) once to close the window and return 
to your original screen. If you are not using a mouse, please use the F3 and F4 function 
keys (marked Select and View) as indicated at the bottom of the screen, (see Figure 1). The 
F3 key allows you to select the different hypertext topics. Once the desired topic is selected 
(i.e. highlighted), the F4 key calls the background information for view. 

Multiple page displays are indicated by the Pg 1 of 2 message at the lower right of the 
screen. To navigate through multiple screen displays, please use the Page Up and Page 
Down keys to scroll either forward or backward through the pages. 


"Automated Payload Experiment Tool" 

So you want to fly on the Shuttle. 

Well before you can, we must get a little information about 
your experiment and its objectives. 


If you have flown with us in the past, you may remember a substantial 
amount of paper documentation was r equired. This application, the 
(jijgn^^^gyloSMEl^i^BRcpi'l is designed to alleviate much 
of the burden of the preparation process by utilizing a[ 

knowledge-based system. This sy stem can currently be used to prepare 
one of the support documents, the 

which provides an envelope or volume of science requirements for a type of 
experimentation. 

Press SPACE to continue. 


FI Help 

F3 Select 


Pg 1 of 1 

Space Cont. 

F4 View 

F8 DOS 

F10 Quit 


Figure 1 

Sample Screen Layout Using Hypertext 


For help at anytime throughout the APET application, press the FI key. This will 
retrieve location sensitive help information, and may be called from the system or system- 
called edit screens. This will be the method by which assistance information will be 
retrieved throughout this application. 
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APET has been designed as a menu-driven software package. This means that any 
function required of the user can be activated via a menu option. This includes exiting the 
system. It is strongly recommended that the user always "back out" of the application by 
using the appropriate menu options, i.e. "Return to Previous Menu". An option does exist to 
exit from any point in the application by selecting F10. It is not recommended that this be 
used from inside a question/answer section of the application. The F10 command causes an 
immediate exit from the program, without checking to ensure that open files have been 
properly saved. Therefore, the user may experience data loss if the application is exited in 
this manner. 

After the installation and initial use of the APET software, future sessions will be 
initiated by going to the C:\GARDEN subdirectory and typing ENVELOPE. This will 
activate the software and present the opening menu, (see Figure 2). 

i — "Automated Payload Experiment Tool' 1 1 


Please select the activity of your choice, or choose Exit 
to leave the system. 


How to use the System 
Project Selection 

Science Requirements Envelope Document (Overview) 

Glossary/Acronyms 

Print Glossary/ Acronyms 

Exit System 


FI Help 




F8 DOS 

F10 Quit 


Figure 2 

Opening APET Main Menu 

Due to the hypertext capabilities of the APET software, a large amount of RAM (random 
access memory) is required. Because of the heavy RAM demand, proper execution of the 
software requires no other software package be running simultaneously with the APET 
software. Whenever the available RAM becomes too little for the application, an 
"Insufficient Memory" message will be shown at the bottom right of the screen. To alleviate 
this situation, simply get out of APET and reboot the system. This will usually free up all 
available RAM and ensure proper execution, (see Helpful Hints for further instruction.) 
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3.0 USING THE APET SYSTEM 


3.1 How to Use the System 

Because the use of a hypertext tool may be a new experience, a brief on-line tutorial is 
provided with APET. To use this tool, please choose option one on the opening menu 
entitled "How to Use the System". To select this option, point with the mouse to the phrase 
and click. If not using a mouse, use the arrow keys to highlight the option and press 
RETURN. You can tell when an option has been selected because it (the phrase or word) 
will be highlighted differently from all other options. As the mouse is moved to other 
options, each in mm will be highlighted. 

Once the "How to Use the System" option has been selected, a different screen will be 
presented with a brief overview of hypertext and the methods of selecting topics. (This 
overview is much the same as appears in Section 2.4 of this users guide.) Practice selecting 
topics and moving from one screen to another using either the mouse or the appropriate 
keyboard function keys. 

3.2 Pro ject Selection 

The APET software package will accommodate one or more experiments for the user. 
However, each experiment must be identified by a short (8 characters or less) name, which 
must conform to the naming convention used by the DOS computer operating system. 
Briefly, these mles state that a DOS name cannot be over 8 characters in length, and must 
contain a combination of either letters, numbers, or the underscore (_) character. Any other 
special keys, including the SPACE, are prohibited. The rationale behind this naming 
convention is to allow storage of data files for each experiment in a subdirectory for that 
specific experiment. For example, if a user is working on two experiments, identified as 
THINFILM and HIPROTEN, then there would be a subdirectory for each. The 
configuration of these files would be as follows: 



C:\ 


A pplication Directory Experiment Directory 

.... GARDEN) THINFILM 

HIPROTEN 


Therefore, all data files conta inin g answers for the APET questions for the experiment 
TFQNFILM would appear in the subdirectory THINFILM. If additional experiments are 
required, the user would identify the new experiment and an additional subdirectory would 
be added. 
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Figure 3 shows the menu for selecting, adding, or deleting an experiment project. In the 
example, the experiment AADSF_L has been previously defined by the user. If the user 
wants to work on this experiment, he simply points and clicks on this selection. (This would 
be the case in a majority of the cases, since most Principal Investigators will have only one 
active experiment at any given point). However, if another experiment is required, the user 
would click on "ENTER A NEW PROJECT". The user would be prompted to identify the 
new experiment, and would immediately be passed into the APET system, where information 
regarding that experiment would be addressed. 

i— "Automated Payload Experiment Tool" 1 


Please select the project of your choice, or enter a new 
project. 


AADSFL 

ENTER A NEW PROJECT 
DELETE AN OLD PROJECT 
RETURN TO MAIN MENU 


L 


1 

FI Help 

F8 DOS 

F10 Quit 


Figure 3 

Project Selection/Identification Menu 


If a user wishes to delete an experiment, along with all its associated data files, he may 
do so by selecting the "DELETE AN OLD PROJECT" option from the menu. However, 
there is qq recoverable procedure to undelete a project. Therefore, the user is strongly 
advised to use this procedure with caution. 

3.3 Science Requirement Envelope Documen t Overview 

The third selection from the APET Main Menu is the "Science Requirement Envelope 
Document Overview". This option should be selected when the user wishes to see an 
overview of the Science Requirement Envelope Document, along with brief explanations of 
the information to be covered in each section/subsection of the document. For an additional 
overview of the topics to be addressed in the Science Requirement Envelope Document, see 
Appendix A of this document. 
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3.4 Glossary/ Acronyms 


A number of NASA specific terms, definitions, and acronyms will appear as support 
material throughout the documentation process. One of the primary advantages of using a 
hypertext-based tool is to allow for easy and immediate retrieval of these terms. 

Option number five from the APET Main Menu allows the user to retrieve a listing of 
these terms, and presents them in a form analogous to a glossary in a book. To view a 
definition, highlight the desired term and click. A term can be highlighted by using the 
mouse to move the cursor to that word, or by using the F3 key for selection. To view the 
definition, the user should either click the mouse or press the F4 key. The definition of that 
word/term will be presented. Should the definition contain a term that requires further 
description, highlight that word and click. The new definition will overlay the previous 
definition. This method can be repeated as long as further definitions exist and the memory 
capacity of the machine is not exceeded. 

Please note that the glossary consists of multiple pages. Remember to navigate through 
the multi-page displays by using either the Page Up/Page Down function keys. 


3.5 Print Glossary/ Acronyms 

Option number six from the APET Main Menu activates a routine for the printing of the 
glossary /acronym list, as discussed in Section 3.5. Because the output of this selection will 
be a multi-page document, the use of this option will be rare. 


3.6 Filling Out the Science Requirements Envelop e Document 

To fill out the Science Requirements Envelope Document, the user must first select 
"Project Selection" from the APET Main Menu. Then the Project Selection/Identification 
Menu (Figure 3) will be presented for the user to identify either a new project or select an 
existing project. Once the selection/identification has been made, the Science Requirement 
Envelope Document Activity Menu (Figure 4) will be presented. Please note that the 
selected project is shown on the upper right comer of the screen. Please be sure that the 
project shown is the one you wish to work. 
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FI Help 




F8 DOS 

F10 Quit 


Figure 4 

Science Requirements Envelope Activity Menu 


The Science Requirements Envelope Document Activity Menu presents ten options for 
the user. The most significant of these is the first: "FILL OUT DOCUMENTATION". The 

selection of this option will present the Fill Out Science Requirements Envelope 
Documentation Menu (Figure 5). This menu offers the user three new options: "ENTER 

PROJECT INITIALIZATION INFORMATION", "COMPLETE SCIENCE REQUIREMENTS ENVELOPE", 
and "MARK QUESTIONS IN THE SCIENCE REQUIREMENTS ENVELOPE AS 'NOT APPLICABLE’". 

i— "Automated Payload Experiment Tool" 1 


Please select the activity you wish to perform on 
the ADDSF L project. 


Enter Project Initializatm Information 

Complete Science Requirements Envelope Document 

Mark Questions in the Science Requirements Envelope as 'Not Applicable' 

Return to Previous Menu 

Return to Main Menu 

Exit System 


FI Help 




F8 DOS 

F10 Quit 


Figure 5 

Fill Out Science Requirements Envelope Documentation Menu 
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3.7 Entering Project Initialization Information 


Under most circumstances, the first information entered by the user into the APET 
system is the project initialization information. To enter this information, select option one 
from the Fill Out Science Requirements Envelope Documentation Menu. This information is 
used to identify certain aspects of the experiment, and will be used throughout the 
documentation process. Entries include the PI name, organization, address, city, state, zip, 
phone, and experiment title. This information will be provided in the form of type written 
responses to user prompts. For example, the user will be asked: 


Please enter your first and last names, i.e. Dr. John Doe. 


The user should respond with a one line response. (If there is a limitation on the length 
of this one line response, the screen display will provide an instruction, such as "Please limit 
your response to 16 characters.") This will be the format of user entries throughout the 
APET application. When the user is prompted to make an entry, the response should be on 
one line. When the user responds with a RETURN, the answer is stored and the next 
question, if one exists, is asked. Once all questions for that segment have been answered, 
the answers are written to a data file. 

In the "Project Initialization Information" subsection, the only variation in the user 
prompt/one line response routine is with the experiment title. Because experiment titles can 
be several lines, the user is given a prompt and immediately sent to the APET editor. This 
editor is a small version of a word processor, with many of the functions of a common word 
processing package. The commands used in the APET editor are similar to those in the 
software package WORDSTAR. To see the commands available, press the FI function key 
from inside the editor. A separate window will be opened and will overlay the current 
screen. From there, page down until the function you wish to perform is shown. The one- 
to-two keystroke command to accomplish the task will be shown. (Note: The symbol O 
represents the CONTROL key, i.e. ~KQ means to hold the CONTROL key down while 
pressing the letter K, then press the letter Q.) When the user is finished entering the answer 
into the editor, he may exit by pressing the ESC (escape) key. A message will then appear 
on the screen that tells the user what file name is being saved. Respond with a RETURN to 
accept this name and save the answer, or an ESC to cancel the answer. 

Important: Do not change the file name when the APET software asks if the name is 
acceptable. Future sessions that allow the user to change, delete, print, or display the SRD 
answers require that these file names be used. Changing the file name will make the file 
either inaccessible or inappropriate. Therefore, always accept the file name as given. 
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3.8 Complete Science Requirements Envelope Document 


To complete the Science Requirements Envelope Document, there are between 30 - 40 
questions that must be answered. These answers will be in the form of short narratives, 
consisting of one or more paragraphs of text. Each question or user prompt will invoke the 
APET editor and give the user sufficient space to write as much (or little) as required. A 
sample question from the Science Requirements Envelope Document is shown in Figures 6. 


Description of Experiment Type or Class (Question 1 of 39)“ 


Please enter a narrative description of the type or class of the experiment 
This topic is also addressed under the headings: 

"Experiment Procedures to be Used" and 
"General Description of Type of Experiments". 

Press RETURN to enter the editor, ESC to exit the editor, and RETURN 

to confirm save. 

C:\GARDEN\AADSF LAENVl l.DAT 


V- 


ENTER TEXT ANSWER HERE. 


FI Help 


F8 DOS 


F10 Quit 


Figure 6 

Science Requirements Envelope Document 
Sample Question 

The Complete Science Requirements Envelope Document session begins by asking the 
user if he has begun to fill out the Science Requirements Envelope Document previously. A 
'NO' response causes the questions to be asked in sequence. A 'YES' response results in the 
question topics to be displayed in a list. If questions are to be answered from a list, a list 
will appear as a window that overlays the question screen. The user is expected to point-and- 
click on the appropriate topic. (If not using a mouse, use the arrow keys to select and press 
RETURN.) The user should click on the appropriate answer with the left-side mouse button. 

For the initial Science Requirements Envelope Document session, the user would respond 
with a NO and proceed to the questions. These questions will be asked in the same sequence 
as is shown in the outline. After each response, the user will be asked if he wants to 
continue to the next question. This gives the user a chance to end the session when desired, 
rather than advancing through all the remaining questions. The title of each question screen 
will include the number of the question (i.e., Number 1 of 39). This allows the user to see 
where he is in the process and respond accordingly. 
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If the user responds with a 'YES', which means there has been a previous session, the 
following question will appear: 

Do you wish to change only one item, resume at a point 
and continue sequentially through the remainder of the 
SRD, or complete all topics previously unanswered? 

This allows the user one of three options. 1) He may select the one answer that needs 
changing, go directly to that answer and change it, then record that answer to disk. 2) He 
can select the topic where he would like to resume his activities, answer that question, record 
the answer, and go to the next question in sequence. This gives the user the capability of 
selecting the 20th question, and proceed sequentially through the remaining 19 questions. 3) 
The user can complete all questions that have not yet been answered. This option will 
invoke a command to look at what answers (files) do not exist, and build a list of these 
topics. The user then selects the topic to answer, answers the question, records the answer, 
and goes to the next question of his choice. With each recorded answer, that topic is 
removed from the list. 

3.9 Mark Questions in the Science Requirements Envelope as .'Not Applicable' 

The Science Requirements Envelope Document questions used in APET are taken 
directly from the Microgravity Science and Applications Division (MSAD) Management 
Plan. However, the PI and his NASA project manager may determine that some of these 
questions do not pertain or are not necessary for the completion of the Science Requirements 
Envelope Document. In order to simplify the Science Requirements Envelope Document 
preparation process, the ability to mark multiple questions as 'Not Applicable' has been 
provided. This option would probably be chosen as one of the first actions taken in 
preparing the Science Requirements Envelope Document. 

Upon selecting this option from the menu, the user will be requested to choose the topics 
to mark as ' 'Not Applicable’ ’ by one of the two methods. This choice depends on whether a 
mouse is being used. For mouse users, topics will be selected by clicking the RIGHT side 
mouse button on each topic to be marked. When the list is complete, click the LEFT side 
mouse button. To navigate through the multiple page listing, click on the Pg 1 of 4 message 
at the bottom of the list. 

Non-mouse users are instructed to use the arrow keys to move to the topic to be selected, 
then use the Insert key to select it. To move from one page to another, use the Page 
Up/Page Down keys. When the list is complete, press the RETURN key. 

All topics selected will be given the answer 'Not Applicable'. However, any questions 
that have been previously answered will not be changed, and a warning message to that effect 
will appear on the screen. This safeguards against the user accidentally destroying a valid 
answer by choosing this option. If an answer is required to be changed to 'Not Applicable', 
then the user must select the topic from the 'Change One Item' option (see Section 3.8). 
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3.10 Printing the Science Requirements Envelope Document 

The user has three methods available to generate output from the APET software. These 
include printing the document, displaying the document, and creating an ASCII file of the 
document. The APET application was designed to be flexible enough to go to a variety of 
printers. As with most output, the best results will be with the use of a laser printer. If a 
laser printer is not available, the use of a dot-matrix printer will also be acceptable. A 
variety, although not nearly exhaustive, of dot-matrix printers have been tested with the 
APET software, and all have performed well. 

If the document has previously been baselined (discussed later in Section 3.13), then a 
menu will appear giving the user the option of printing the document from the baselined 
version, the current revision, or neither version. If the neither option is chosen, then it is 
assumed that the user does not want the document printed, and the program will 
automatically return to the previous menu. If the baseline option is chosen, then the 
document will be printed from the file which is in the project baseline subdirectory. If the 
current revision option is chosen, then the document will be printed from the version of the 
document which the user is currently revising. If the document has not been baselined, then 
the document will be printed from the current version. 

The printing of the Science Requirements Envelope Document will generate the document 
in its entirety. An initial page eject will normally (depending on printer type) advance a 
blank sheet of paper before the cover sheet is printed. This will be followed by a second 
page advance, then page one of the document will be printed, followed by two, three, etc. 
through the end of the document. Because there are often graphics, tables, etc. that must be 
inserted within the textual document, no table of contents is printed. Because of the 
limitation of graphics support, it is suggested that all externally generated graphic 
illustrations, tables, etc. be provided in an appendix, with appropriate references throughout 
the document. 

While the print procedure is active, a message will appear in the lower left of the screen. 
No other activities may take place while the document is printing. In case the printer runs 
out of paper, an error message will appear. Reload paper in the printer and press the 
SPACE key to continue. 

3.11 Displaying the Science Requirements Envelope Document 

The second method of generating output using APET is to display sections of the Science 
Requirements Envelope Document to the screen. The Science Requirements Envelope 
Document is divided into seven major sections, with each divided into one or more 
subsections (see Appendix A). The user has the capability of selecting a section and seeing 
the identical output as would appear if the document was printed. Displaying the Science 
Requirements Envelope Document is recommended to quickly review answers, especially 
during the development phase of document preparation. 
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If the document has previously been baselined (discussed later in Section 3.13), then a 
menu will appear giving the user the option of displaying the document from the baselined 
version, the current revision, or neither version. If the neither option is chosen, then it is 
assumed that the user does not want the document displayed, and the program will 
automatically return to the previous menu. If the baseline option is chosen, then the 
document will be displayed from the file which is in the project baseline subdirectory. If the 
current revision option is chosen, then the document will be displayed from the version of 
the document which the user is currently revising. If the document has not been baselined, 
then the document will be displayed from the current version. 

Most Science Requirements Envelope Document sections will require multiple page 
displays. Please note that to view the equivalent of an entire printed page, there will be at 
least three and usually four screen displays. Use the Page Up/Page Down method to move 
up or down in the document. Once a page is adequately reviewed, press the SPACE key to 
retrieve the next page in sequence. To abandon a display at any time, press the F10 key. 

3.12 Create an ASCII File of Science Requirements Envelope Document 

The APET software does not have the ability to generate or insert graphics, charts, etc. 
that were created in some other application. This is primarily due to the memory size 
limitations of the computer. However, to alleviate this limitation, APET does have the 
ability to generate an ASCII file of its Science Requirements Envelope Document output. 
After choosing this option, the user need only type in the full file name (includes drive, file 
name, and extension). The file will then be created as a replica of the printed output. 

The benefit of creating an ASCII text file of the Science Requirements Envelope 
Document is in providing the user with the capability of enhancing the final printing by 
inserting graphics, photos, tables, equations, or other difficult to create figures. In addition, 
different fonts, font sizes, and special effects can be used to dress up the final printed output. 

3.13 Baseli ni ng a D oc u m ent 

At some point in the documentation procedure, the Science Requirements Envelope 
Document will be considered complete and released to external offices, agencies, 
organizations, etc. When this occurs, that version of the document is considered the 
baseline, and should be easily identified as such. 

To aid in the process of maintaining separate versions of the Science Requirements 
Envelope Document, an option exists to baseline the current version of the document, (see 
Figure 7). The selection of this option will cause a replica of the current version's answers 
(or data files) to be copied to a new subdirectory for that experiment. This new subdirectory 
will be called BASELINE. From that point, all additional editing will transpire on a new 
version of the answers, while the baselined version of the answers will remain intact. The 
generation of output will require the user to identify which version (baseline or current 
revision) he wishes to access. 
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Automated Payload Experiment Tool 


At some point in the documentation process, it is necessary to 
declare that all documents are complete, and that any changes 
to be made will be treated as revisions to the baseline document. 

Do you want to baseline your answers at this time? 


YES 

NO 


1 

FI Help 

F8 DOS 

F10 Quit 


Figure 7 
Baseline Menu 


3.14 Comparing a Baseline to the Current Revision 

Once the document has been baselined (see Section 3.14), the user may wish to compare 
this baseline with the current revision. APET provides a mechanism to accomplish this task. 
By selecting the option "Compare Baseline to Current Revision", a DOS routine will be 
invoked to compare all identical data files from the current revision to the baseline document. 
This comparison generates a file that can then be displayed or printed, so that a quick review 
will show which answers have been modified since the original baseline date. 

3.15 Copying Answers to Disk 

The final output option provided by APET is the creation of files that contain all data 
generated by the software. This can be used as either a backup mechanism during the 
creation of the files, or as a means of submission of the final document instead of a hard 
copy /printed document. By submitting the answers on diskette, the receiving party can have 
direct access to the answers in the same manner as would the sender. These files are not 
formatted as an ASCII file, and should not be confused with the final report output, which 
can be created using the "Create an ASCII File of SRD" (discussed in Section 3.13). 

The user will have the option of selecting either the baseline document or the current 
revision. After this selection, the user is asked to select the drive to receive the backup 
(either A:,B:,C:, or D:). A DOS copy command will then be invoked to copy all files to the 
selected drive. 
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4.0 HELPFUL HINTS 


1) Avoid the use of the F10 key to exit from within the APET application. It is a better 
practice to "back out" of the APET system through the use of the menus. By doing so, the 
user ensures that all answers are properly recorded to the disk drive. Use of the F10 key 
from within the APET application will allow the user to exit but will not automatically save 
information generated during the session. 

2) APET does not support the insertion of externally generated graphics, tables, 
equations, or other non-text material. To alleviate this problem without the added labor of 
using a secondary word processor, it is suggested that any such material be included in an 
Appendix, and referenced in the text generated in APET. 

3) To insert an externally generated text file into the text area in the APET editor, use 
the command ~KR from within the editor. This is one of a variety of commands that can be 
used from the APET word processor. To see all available commands, press the FI key from 
inside the editor and page through the instruction set. 

4) The APET editor uses a word wrap routine that automatically wraps the line to the 
next line (a common word processing feature). It also maintains vertical alignment along the 
left margin. If you use indented paragraphs, please be sure that the line after the indented 
line begins in the column you desire. To do this, use the backspace key to move the first 
word in the line to the column desired. The recommended solution to this problem is not to 
indent paragraphs, but instead insert a blank line between each paragraph. 

5) If your computer system is configured to automatically load WINDOWS or some 
other application package, it may be necessary to alter the AUTOEXEC.BAT file (located in 
the boot drive). Instructions for changing the automatic load of an application will vary by 
computer. One of the easier methods is to edit the AUTOEXEC.BAT file and remove the 
line that calls the package. For example, WINDOWS is called by the command WIN. By 
preventing these packages from loading, a significant amount of RAM is freed and allowed 
for use by APET. 
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APPENDIX A 


Science Requirements Envelope Document 
Topic Outline 


1.0 INTRODUCTION/SUMMARY 

1.1 Description of Experiment Type or Class 

1.2 Scientific Knowledge to be Gained From This Type of Experimentation 

1.3 Value of Knowledge of This Type of Experiment to Scientific Field 

1 .4 Necessity for Space Environment to Experiment Type 

2.0 BACKGROUND 

2.1 Scientific Field to which Experiment Type Belongs 

2.2 Current Application for Research in the Field 

2.3 Brief Historical Account of Prior Research in the Field 

2.4 Current Research 

2.5 Relationship of Proposed Experiment Type to Experiment Field 

2.6 Anticipated Advance in State of the Art for This Type of Experimentation 

3.0 JUSTIFICATION FOR CONDUCTING THE EXPERIMENT IN SPACE 

3.1 Limitations of Ground-Based Testing 

3.2 Limitations of Drop Towers 

3.3 Limitations of Testing in Aircraft 

3.4 Need for Accommodations in the Shuttle 

3.5 Limitations of Mathematical Modeling 

3.6 Limitations of Other Modeling Approaches 

4.0 DESCRIPTION OF EXPERIMENT TYPES 

4.1 General Description of Type of Experiments 

4.2 Types of Experiment Procedures to be Used 

4.3 Types of Measurements and Ranges of Values Required 

5.0 SCIENCE REQUIREMENTS ENVELOPE 

5.1 General Description of Experiment Sample Requirements 

5.2 Range of Atmospheric Requirements 

5.2.1 Pressure 

5.2.2 Gas Composition 

5.2.3 Humidity 

5.2.4 Vacuum 

5.3 Temperature Control and Measurement 

5.4 Vibration Control and Measurement 

5.5 Test Matrices 
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5.6 Imaging Requirements Envelope 

5.6.1 Photography 

5.6.2 Radiography 

5.6.3 Television 

5.6.4 Resolution 

5.6.5 Frame Rate 

5.7 Electromagnetic Limitations 

5.8 Astronaut Involvement 

5.8.1 Extravehicular Activity 

5.8.2 Activation of Experiment 

5.9 Data Requirements 

5.10 Telepresence and Telerobotics 

5.10.1 Telepresence 

5.10.2 Telerobotics 

6.0 OTHER REQUIREMENTS 

6. 1 Research Equipment 

6.1.1 Preflight 

6. 1 .2 Post flight 

6.2 Apparatus Design Assistance 

6.3 Consultation 

6.4 Grants and Contracts 

6.4.1 Grants 

6.4.2 Contracts 

6.5 Services 

6.5.1 Film Developing 

6.5.2 Software Development 


APPENDIX B 


APET Editor Co mm ands 


MOVING THE CURSOR: 


A D Left One Character 

A S Right One Character 

A A Left One Word 

A F Right One Word 

A I Tab 

A E Up One Line 

A X Down One Line 

A W Scroll Up 

A Z Scroll Down 

A R Page Up 

A C Page Down 

A QS Beginning of a Line 

A QD End of a Line 

A QE Beginning of a Page 

A QX End of a Page 

A QR Beginning of a File 

A QC End of the File 

A QB Beginning of Marked Block 

A QK End of Marked Block 


DELETING AND INSERTING TEXT: 

A G 

A H 

A'p 

A Y 

A QY 

A KY 

A V 

A N 

BLOCK COMMANDS: 


A KS Save This File 

A KB Mark Beginning of Block 

A KK Mark End of Block 

A KH Hide / Display Block 

A KC Copy a Block 

A KV Move a Block 

A KY Delete a Block 

A KR Read a Block from a File 

A KW Write a Block to a File 

A KP Print a Block or File 


Delete Character Under Cursor 
Delete Character Left of Cursor 
Delete Next Word 
Delete a Line 

Delete to the End of a Line 
Delete a Marked Block 
Insert On/Off 
Insert a Line 
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FORMATTING COMMANDS: 


Reformat Paragraph 

A OR Set Right Margin 

A QI Toggle Auto indent Mode 

"QW Toggle Word Wrap 


FIND AND REPLACE COMMANDS: 


^QA Find and Replace a String 

A QF Find an Occurrence of a String 

Find the Next Occurrence 
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For assistance in using this software, 
or to offer suggestions or comments, 
please contact the following: 

Mr. Gary Maddux 
Ms. Anna Provancha 
Mr. David Chattam 

at (205) 895-6343, 
or write 

Systems Management and Production Laboratory 
Research Institute 
RIE-47 

The University of Alabama in Huntsville 
Huntsville, AL 35899 


APPENDIX D 


Safety Requirements Document Software Listing 


(*SAF12MEN. KB This is the activity menu to allow the *) 

(* user to select an activity to perform on *) 

(* an existing project. *) 

no_edit_key ( ) . 

no_debug () . 

do_gloss = 1 . 

yn is [YES, NO] . 

eof = number_to_char (26) . 

curdir is read_line ( ' CURDIR. DAT' ) . 
orig_curdir = ?curdir. 

close (concat ( ' C : \GARDEN\ ' , ? CURDIR, ' \ BASELINE . DAT' ) ) . 
curdir is string_replace (?curdir, 8) . 

menu_option is ['FILL OUT DOCUMENTATION', 

' PRINT PED SAFETY COMPLIANCE DATA PACKAGE ' , 

'DISPLAY PED SAFETY COMPLIANCE DATA PACKAGE', 

'BASELINE PED SAFETY COMPLIANCE DATA PACKAGE', 

'COMPARE BASELINE TO CURRENT REVISION', 

'COPY ANSWERS TO DISK', 

'RETURN TO PREVIOUS MENU', 

'RETURN TO MAIN MENU' ,QUIT] . 

window ('Safety Compliance Data Package' , blue , white, white, 3 , 3 , 76 , 17) . 
menu_choice - ‘ . 

while ?menu_choice <> QUIT 
then do (nasamenu) . 

topic nasamenu. 

ask (['#e #n#n#s The project you have selected is: ' , ?curdir , ' #d #n 

Please enter your choice of activities from the list . ' ] ,menu_choice, 
?menu_option) . 

if ?menu_choice = 'FILL OUT DOCUMENTATION' 
then new_kb ( ' SAF JAO 12 . HKB ' ) . 

if ?menu_choice = 'RETURN TO PREVIOUS MENU' 
then new_kb ( ' SAF 12 PRO . HKB ' ) . 

if ?menu_choice = 'RETURN TO MAIN MENU' 
then new_kb ( ' SAF12 . CKB ' ) . 

if ?menu_choice = 'PRINT PED SAFETY COMPLIANCE DATA PACKAGE' 
then 

new_kb ( ' SAF12PRN . HKB ' ) . 

if ?menu_choice = 'DISPLAY PED SAFETY COMPLIANCE DATA PACKAGE' 
then 

new_kb ( ' SAF12DIS . HKB ' ) . 

if ?menu_cho ice = 'BASELINE PED SAFETY COMPLIANCE DATA PACKAGE' 
then do (baseline_rtn) . 

if ? menu_cho ice = 'COPY ANSWERS TO DISK' 
then do (copyfiles) . 
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if ?menu_choice = 'COMPARE BASELINE TO CURRENT REVISION' 
then do (compare_rtn) . 

if ?menu_choice = QUIT 
then stop () . 

topic 'copyfiles'. 

drive_destination = [] . 
base_dir = [] . 

ask ( ' 

Do you want to copy your answers to a different drive? ', wantcopy, ?yn) . 

if ?wantcopy = YES 
then 

base_dir = [] 
and 

curbase is read_line (concat ( ' C : \GARDEN\ ' , 7CURDIR, ' \BASELINE . DAT' ) ) 
and 

close (concat ( ' C : \GARDEN\ ' ,?CURDIR, '\BASELINE.DAT' ) ) 
and 

if ?curbase <> ?eof 
then 

base_choice = [' BASELINE' ,' CURRENT REVISION' , 'NEITHER' ] 
and 

ask ( ' #e 

Do you wish to copy files from the baseline or 
the current revision? ', base_dir, ?base_choice) 
and 

if ?base_dir = BASELINE 
then 

curdir = concat (?curdir , ' \BASELINE' ) 
and 

curdir = string_replace (?curdir , ' ' , ' ' , 8) 
and 

new_f ile ('C:\GARDEN\CURDIR.DAT') 
and 

write ('C:\GARDEN\CURDIR.DAT' ,? cur dir) . 
if ?wantcopy = YES 

then drivel ist is [A: ,B: ,C: ,D: ,NONE] 
and 

if ?base_dir <> NEITHER 
then 
ask 
( ' #e 

Please choose the drive to which you wish to copy the files : ' , 
drive_destination,?drivelist) . 

if ?wantcopy = YES and ?drive_destination <> NONE and ?base_dir <> NEITHER 
then 

copy_command = concat ('COPY C : \GARDEN\ ' , ? curdir , ' \* . DAT ' , ?DRIVE_DESTINAT 
and 

say (' 

Please insert diskette now if you are copying to a floppy drive. 

Please press #fyellow SPACE#d when ready. ') 


D-2 


and 

move_cur sor (1,10) 
and 

dos (?copy_command, restore) 
and 

say ( ' #e 


Answers have been copied to drive #s' , ?drive_destination, ' #n #n 


Please press #fyellow SPACE#d to exit. ') . 

if ?base_dir = BASELINE 
then 

curdir = ?orig_curdir 
and 

curdir = string_replace (? curdir, ' ' , ' ' , 8) 
and 

new_f ile ( ' C : \GARDEN\ CURDIR . DAT ' ) 
and 

write ('C:\GARDEN\CURDIR.DAT' , ?curdir) . 

do (nasamenu) . 

end. (* copyfiles *) 

topic 'baseline_rtn' . 
today = date () . 
month = element (?today, 1) . 
day = element (?today, 2) . 
year = element (?today, 3) . 

today = concat (?month, ' / ' , ?day, ' / ' , ?year) . 
ask ( ' #e 

At some point in the documentation process, it is necessary to 
declare that all documents are complete, and that any changes 
to be made will be treated as revisions to the baseline document . 

Do you want to baseline your answers at this time?' , baseline, ?yn) . 

curbase = ?eof . 
overwrite = YES . 
if ?baseline = YES 
then 

curbase is read_line ( concat ( ' C : \GARDEN\ ' , ? CURDIR , ' \BASELINE . DAT ' ) ) 
and 

close (concat ('C:\GARDEN\' , ? CURDIR, '\BASELINE.DAT' ) ) 
and 

if ?curbase <> ?eof 
then 
ask 

( ' #e 

You have already baselined this experiment in the past. Do you 
want to take all revisions and overwrite your previous baseline 
to create a new baseline? ', overwrite, ?yn) . 

if ?curbase = ?eof and ?baseline = YES 
then 
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window (, white, red, yellow, 1, 14 , 32 , 6) 
and 

say ( ' #e 

This selection will invoke 
a DOS command, which will 
cause your screen to blank 
out momentarily. Do not 

be alarmed. Press #fyellow SPACE#d now. ' ) 
and 

md_command = concat ('MD C : \GARDEN\ ' , ?curdir , ' \BASELINE' ) 
and 

dos ( ?md_command , restore ) 
and 

c°py_command = concat 

('COPY C : \GARDEN\ ' , 7CURDIR, ' \* . DAT C : \GARDEN\ ' , 7CURDIR, ' \BASELINE\* 

and 

dos ( ?copy_command, restore ) 
and 

write (concat ( ' C : \GARDEN\ ' , 7CURDIR, '\BASELINE.DAT' ) , ?today) 
and 

close_window ( ) 
and 

say ( ' #e 

Baseline document has been created. All changes to this 
document will be stored in the revision. A new baseline 
must be created to incorporate any revisions into the 
final document. 


Please press #fyellow SPACE#d to exit. '). 

if ?curbase <> ?eof and Pbaseline = YES and ?overwrite = YES 
then 

xcopy_command = concat 

( ' XCOPY C : \GARDEN\ ' , 7CURDIR, ' \* . DAT C : \GARDEN\ ' , 7CURDIR, 

' \BASELINE\* . * /D: ' , 7CURBASE) 

and 

window ( , white, red, yellow, 1,14,32,6) 
and 

say ( ' #e 

This selection will invoke 
a DOS command, which will 
cause your screen to blank 
out momentarily. Do not 

be alarmed. Press #f yellow SPACE#d now. ') 
and 

dos ( ?xcopy_command, restore) 
and 

new_f ile (concat (' C: \GARDEN\ ' , 7CURDIR, ' \BASELINE . DAT' ) ) 
and 

write (concat ('C:\GARDENX ' , 7CURDIR, ' \BASELINE.DAT' ) , 7 today) 
and 

close_window ( ) 
and 

say { ' #e 

All revisions have been incorporated in the baseline 
document. Addition changes to this document will be 
stored in a new revision. A new baseline must be 
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created to incorporate any new revisions into the 
final document. 


Please press #fyellow SPACE#d to exit. '). 


do (nasamenu) . 
end. (* baseline_rtn *) 
topic ' compare__rtn' . 

close (concat ( ' C : \GARDEN\ ' , ? CURDIR, '\BASELINE.DAT' ) ) . 

curbase is read_line (concat (' C : \GARDEN\ 7CURDIR, ' \BASELINE. DAT' ) ) 

and 

close ( concat ( ' C : \ GARDEN \ ' , ? CURDIR , ' \ BASELINE . DAT ' ) ) 
and 

if ?curbase = ?eof 
then 
say 
( ' #e 

You have not yet baselined this experiment; therefore, 
no comparison is necessary. 


Press #fyellow SPACE#d to continue' ) 

and 

new_kb ( ' SAF12MEN . HKB ' ) . 

COmp_choices = ['RUN COMPARISON PROGRAM' , 'DISPLAY COMPARISONS', 

'PRINT COMPARISONS' , 'RETURN TO PREVIOUS MENU'] . 


ask ( ' #e 

Do you wish to run the comparison program to generate a new 
listing of differences between the baseline and revision, 
print or display the results of the most recent comparison, 
or exit this menu? ' , comp_ans, ?comp_choices) . 

if ?comp_ans = 'RETURN TO PREVIOUS MENU' 
then new_kb ( ' SAF12MEN . HKB ' ) . 

if ?comp_ans = 'RUN COMPARISON PROGRAM' 
then 

do (comp_jpgm) . 

topic 'compjpgm' . 

c omp_c ommand = concat 

('FC /a C : \GARDEN\ ' , 7CURDIR, ' \* . DAT C : \GARDEN\ ' , ? CURDIR , 

' \BASELINE\* . * > C : \GARDEN\' , ? CURDIR, ' \DIFFER.DAT' ) . 
dos (?comp_command, restore) . 

close (concat ( ' C : \GARDEN\ ' , ? CURDIR, ' \DIFFER.DAT' ) ) . 
say ( ' #e 

Files have been compared. Please use the display or 
print options to view the results of the comparison. 

Press #fyellow SPACE#d to continue.'). 
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end. (* comp_pgm *) 

if ?comp_ans = 'DISPLAY COMPARISONS' 
then 

comp_f ile = read (concat (C: \GARDEN\ , 7CURDIR, ' \DIFFER.DAT' ) ) 
and 

say (?comp_file) . 

if ?comp_ans = 'PRINT COMPARISONS' 
then 

comp_f ile = read (concat (C:\GARDEN\, 7CURDIR, ' \DIFFER.DAT' ) ) 
and 

print (#p, ?comp_file, #p) . 
do (nasamenu) . 
end. (* compare_rtn *) 
end. (* nasamenu *) 
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(*SAF12 . KB 

This is 

the opening screen for a knowledge - 

*) 

(* 

based 

system to aid in the development of 

*) 

(* 

NASA documentation for pre- flight planning 

*) 

(* 


and control . 

*) 


yn = [YES, NO] . 
no_edit_key ( ) . 
no_debug () . 
action = ' ' . 

nasaloop = 1 . 
glossary_load = 0 . 
column = 3 . 
row = 3 . 

while ?action <> 'Exit System' 
then do (mainmenu) . 

topic 'mainmenu' . 

choices = ['How to use the System', 

'Project Selection', 

'PPO Payload Safety Implementation Approach Overview', 
'Gloss ary /Acronyms' , 

'Print Glossary/Acronyms' , 

'Exit System'] . 

window (, white, red, yellow, 5, 5 , 75 , 16) . 
set_number_of_values (action, 1). 

ask ('#e 

Please select the activity of your choice, or choose Exit 
to leave the system. ', action, ?choices) . 

close_window () . 

if Taction = 'How to use the System' 
then new_kb ( ' SAFI 2 INT . HKB ' ) . 

if Taction = 'Project Selection' 
then new_kb ( ' SAFI 2 PRO . HKB ' ) . 

if Taction = 'PPO Payload Safety Implementation Approach Overview' 
then 

new_kb ( ' SAF120VR . HKB ' ) . 

if Taction = ' Glossary /Acronyms ' 
then 

glossary_load = (Tglossary_load + 1) 
and 

do (glossary) . 

if Taction = 'Exit System' 
then exit () . 

if Taction = 'Print Glossary /Acronyms' 
then 

ask ( ' #e 

The printing of the glossary/acronym list can require 
a significant amount of time (5 - 10 minutes depending 
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on your system) . Are you sure you want to print the 
glossary at this time? ' ,printok, ?yn) 

and 

if ?printok = NO 

then new_kb (' safety. CKB' ) 
else 

window (, white, red, yellow, 1,16,27,4) 
and 

WRITE ('con:', 

' GLOSSARY is being 
printed. 

Please stand by. ') 

and 

glossaryjprint is read ( 'NASATERM.DAT' , , ' //KSC' ) 
and 

glossary_print is string_replace (?glossaryjprint ,'//', ' ') 

and 

glossary_print is string_replace (?glossary_print , ' /end' , ' ' ) 
and 

print (?glossary_print) 
and 

glossaryjprint is read ( 'NASATERM.DAT' ,' //KSC' ) 
and 

glossaryjprint is string_replace (? glossaryjprint ,'//', ' ') 

and 

glossaryjprint is stringjreplace (?glossaryjprint , ' /end' , ' ' ) 
and 

print (?glossaryjprint) 
and 

close_window () . 

( * **************************************************************** * ) 
topic glossary. 

window ('LISTING OF NASA GLOSSARY AND ACRONYMS' , blue , white, white, 1 , 1 , 80 , 2 0) . 


if ?glossary_load = 1 
then 

window ( , white, red, yellow, 1,16,27,4) 
and 

WRITE ('con:', 

' A slight delay will 
occur while the 
glossary is loaded. 

Please stand by. ' ) 

and 

glossary_text is read ('NASAINDX.DAT') 
and 

close_window () 
and 

close ( ' NASATERM . DAT ' ) . 
say (?glossary_text) . 
close_window () . 
end. (* glossary *) 


topic mark (find_string) . 
column = ?column + 1. 
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row = ? row + 1 . 

text is read (' nasaterm.dat concat ('//', ?f ind_string) /end' ) . 
window ( ?find_string, blue, white, white, ?column, ?row, 72, ) . 
say (?text) . 
column = ? column - 1. 
row = ?row - 1 . 
close_window ( ) . 
end. (* mark *) 

end. (* mainmenu *) 
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*) 

*) 

*) 

*) 


yn is [YES, NO] . 
column = 3 . 
row = 3 . 
no_edit_key () . 
no_debug () . 

tried = 0 . 


(*SAF12INT.KB 

(* 

(* 

(* 


This is an introductory screen for the 
NASA Automated Payload Element Tool . 

It is used to give the novice user a 
brief tour of the functions of the system. 


do ( s o_you_wan t_t o_f ly ) . 

new_kb ( ' SAF12 . HKB ' ) . 

topic so_you_want_to_f ly . 
say ( ' 

#bmagenta So you want to fly an experiment on the Shuttle. #d 


If you have flown with us in the past, you may remember a substantial 
amount of paper documentation was required. This application, 
the #mAutomated Payload Experiment Tool#m (APET) , is designed to 
alleviate much of the burden of the #mexperiment#m document prepar- 
ation and maintenance process. The APET system can be used to 
prepare several of our support documents, including the Science 
Requirements Document (#mSRD#m) , which defines the science objectives, 
the Experiment Requirements Document (#mERD#m) , which defines the 
experiment's design/build requirements, and the PED Safety Compliance 
Data Package, which this specific package addresses. 


if ?tried = 0 
then 


Press #fyellow SPACE#D to continue.') . 


column = ? column + 1 
and 

row = ?row + 1 
and 

window (' ' ,white,red,white,7,5,66,14) 
and 


say ( ' #e 

This application uses #mhypertext#m technology. For more 
information on a highlighted topic, just move the mouse 
to that word and click. The information will immediately 
be displayed. If you are not using a mouse, please use 
the function keys as indicated at the bottom of the screen. 

For multiple page definitions, please use the #fyellow Page Up#d 
and #fyellow Page Down#d keys to scroll back and forth through 
the pages. Multiple page displays are indicated by the 
#f yellow Page x of x #d message at the lower right of the screen. 
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For help at anytime throughout the application, select 
the #f yellow Fl#d key. This will retrieve location sensitive 
help information, and may be called from the system 
or system-called edit screens. 

This will be the method by which support documentation 
will be retrieved throughout this application. 

Press #fyellow SPACE#D to continue.') 

and 

close_window ( ) 
and 

tried = 1 
and 

column = ?column - 1 
and 

row = ?row - 1 
and 

do (so_you_want_to_fly) . 


topic mark (find_string) . 
column = ? column + 1. 
row = ? row + 1 . 

text is read (' nasaterm. dat ', concat {'//', ?find_string) ,' /end' ) . 
window ( ?find_string, blue, white, white, ?column, ?row, 72, ) . 
say (?text) . 
column = ? column - 1. 
row = ?row - 1 . 
close_window () . 
end. (* mark *) 


end. (* so_you_want_to_f ly *) 
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( *SAF12PR0 . KB 
(* 

(* 

(* 

no_edit_key () . 
no_debug ( ) . 
do_gloss = 1 . 
yn is [YES, NO] . 
projlist is ' ' 
do (firstpass) . 


This is the project menu to allow the 
user to define a new project or select 
an existing project. It then calls 
the appropriate submenu. 


if ?pro j ect_want = 'RETURN TO MAIN MENU' 
then new kb ( ' SAF12 . CKB ' ) . 


topic 'firstpass'. 

eof = number_to_char (26) . 
projtest is read_line ('PROJLIST.DAT'). 
if ?projtest = ?eof 
then 

do (new_project) 
else 

projlist is read ('PROJLIST.DAT') 
and 

do (old_project) . 


*) 

*) 

*) 

*) 


topic ' new_project ' . 

window (, white, red, yellow, 5, 5, 75, 16) . 
read_response ( ' #e 

Please enter an identifier for your project. This identifier 
should be eight (8) characters or less. #n ' , newproject) . 

newproject = string_copy (?newproject, 1, 8) . 
newproject = string_replace ( Tnewpro j ect , ' ' , ' ' , 8) . 

IF ? NEWPROJECT <> [ ] AND ? NEWPRO JE CT o' ' AND ? NEWPROJECT <> ' ' 
then 

projlist gets ?newproject 
and 

new_f ile ( ' PROJLIST . DAT' ) 
and 

write ('PROJLIST.DAT' , #o, ?proj list) 
and 

close ('PROJLIST.DAT') 
and 

project_want = ?newproject 
and 

cur_dir = string_replace ( ?pro j ect_want , ' ' , ' ' , 10) 
and 

new_f ile ( ' CURDIR.DAT' ) 
and 

write (' CURDIR.DAT' , ?cur_dir) 
and 

close ('CURDIR.DAT') 
and 

DOSCOMMAND = CONCAT ( ' MD ' , ? NEWPRO JECT ) 
and 

dos ( ? DOS COMMAND , restore ) 
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else 

say ( ' #e 

Sorry, the identifier for your project must be a valid DOS 
name, i.e., eight (8) characters or less. 

Please press #f yellow SPACE#d and begin again. ' ) 


and 

newjcb ( ' SAF12 PRO . HKB ' ) . 
close_window ( ) . 

end. (* new_project *) 

topic ' old_project ' . 

window (, white, red, yellow, 5,5,75,16). 
choose_project = ?projlist. 
choose_j?roject gets 'ENTER A NEW PROJECT' . 
choose_project gets 'DELETE AN OLD PROJECT' . 
choose_project gets 'RETURN TO MAIN MENU' . 
ask ( ' #e 

Please select the project of your choice, or enter a new 
project. ' , pro j ect_want , ?choose_project) . 

if ?project_want = ' ' or ?pro j ect_want = [ ] or ?pro j ect_want = ' ' 
then do (new_project ) . 

if ?pro j ect_want = 'DELETE AN OLD PROJECT' 
then do (kill_project) . 

if ?pro j ect_want = 'RETURN TO MAIN MENU' 
then new_kb ( ' SAF12 . CKB ' ) . 

if ?pro j ect_want = 'ENTER A NEW PROJECT' 
then do (new_proj ect) 
else 

cur_dir = string_replace (?project_want , ' ' , ' ' , 10) 
and 

new_f ile ( ' CURDIR.DAT' ) 
and 

write ( ' CURDIR.DAT' , ?cur_dir) 
and 

close ('CURDIR.DAT'). 

close_window () . 

end. (* old_project *) 

end. (* firstpass *) 

newjcb ( ' SAFI 2 MEN . HKB ' ) . 

topic ' kill jproj ect ' . 
close ('projlist.dat'). 
deletename = ' ' . 

window ( , white, red, yellow, 5 , 5, 75 , 16) . 
ask ( '#e 

You have chosen to delete a project. This will erase all data 
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files for the project from your hard drive, plus will remove 
the project from the list of available projects. This deletion 
is permanent and cannot be undone; therefore, use this option 
with CAUTION. 

Do you wish to proceed with the project deletion? ', 

deleteok, ?yn) . 

if ?deleteok = YES 
then 

read_response ( ' #e 

Please enter the project identifier exactly as it appears in 
the project selection list. This identifier should be eight 
(8) characters or less. #n' , killproj ) . 

oldlist is string_to_list (?projlist) . 

if ?deleteok = YES 
then 

deletename is intersect (?killproj , ?oldlist) . 

deletefnl = NO. 

if ?deleteok = YES 
then 

if ?deletename <> ' ' and ?deletename <> ' ' and ?deletename <> [ ] 
then 

ask ( [ ' #e 

This is your FINAL WARNING. 

#s 

Do you want to delete the project: ', ?deletename, '?'], deletefnl , ?yn) 
else 

say ( ' #e 

This project was not found. Please be sure to type 
project title as it appears on the list, i.e. using 
appropriate upper- and lower-case letters. 

Press #fyellow SPACE#d to continue.'). 

if ?deletefnl = YES 
then 

oldlist is remove (?oldlist , ?deletename) 
and 

new_f ile ( ' PRO JLIST . DAT ' ) 
and 

write ( ' PROJLIST.DAT' , ?oldlist) 
and 

close ('PROJLIST.DAT') 
and 

doscommand = concat ('ERASE C : \GARDEN\' , ?deletename, ' \* . * ' ) 
and 

dos (? doscommand, restore) 
and 

doscommand = concat ('RD ' , ?deletename) 
and 

dos (? doscommand, restore) . 
close_window () . 
new kb ( ' SAF12PRO . HKB ' ) . 
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end. (* kill_project *) 
(* ********************** 
end. (* nasamenu *) 


(*SAF120VR. KB This is the Overview of JA-012 PPO Payload Safety Implementtion 
Approach document that provides the PED with the informtion used to develope 
the Safety Compliance Data Package. *) 

eof = number_to_char (26) . 
column - 3 . 
row = 3 . 

window ('PPO Payload Safety Implementation Approach Overview' , blue, white, 
white, ?column, ?row, 77, 16) . 
say ( ' #e 


This overview limits the access to the referenced documents, however, 
the referenced documents are provided in the section used for filling 
out the Safety Compliance Data Package. 


Press #fyellow SPACE#d to continue.'). 


do (Safety_Compliance_Data_Package) . 

topic mark (f ind_string) . 
row = ?row + 1 . 
column = ? column + 1. 

text is read ('NASATERM.DAT', concat ('//', ?find_string) , '/end'), 
window (?f ind_string, blue, white, white, ?column, ?row, 72,12). 
say (?text) . 
close_window () . 
row = ’row - 1. 
column = ?column - 1. 
end. (* topic mark*) 


topic ' Saf ety_Compliance_Data_Package' . 
firstchoice = ' ' . 


listf irst 


['1.0 

PURPOSE' , 


'2.0 

SCOPE' , 


'3.0 

GENERAL' , 


'4.0 

APPLICABLE DOCUMENTS', 


'5.0 

IMPLEMENTATION APPROACH' , 


'6.0 

SAFETY DATA REQUIREMENTS 

FOR 

'7.0 

SAFETY DATA REQUIREMENTS 

FOR 

'QUIT' 

'] • 



while ’firstchoice <> 'QUIT' 


then 

ask ( ' #e 


NEW MISSIONS' , 

STANDARD ELEMENT MISSIONS', 


The JA-012 PPO Payload Safety Implementation Approach Document 
provides information to the PEDs about their responisbilities 
for documenting the tasks required to evaluate the design and 
operation of the payload element. This documentation is recorded 
in the PED Safety Compliance Data Package. 

JA-012 covers these areas: ', firstchoice, ?listf irst) 

and 

if ?firstchoice = 'QUIT' 
then 

new kb ( ' SAF12 .HKB' ) 
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'1.0 PURPOSE 


else 

if ?firstchoice = 
then 

do ('1.0 PURPOSE') 

else 

if ?firstchoice = '2.0 SCOPE' 
then 

do ('2.0 SCOPE') 

else 

if ?firstchoice = '3.0 GENERAL' 
then 

do ('3.0 GENERAL') 

else 

if ?f irstchoice = '4.0 APPLICABLE DOCUMENTS' 
then 

do ('4.0 APPLICABLE DOCUMENTS ' ) 

else 

if ?f irstchoice = '5.0 IMPLEMENTATION APPROACH' 
then 

do ('5.0 IMPLEMENTATION APPROACH' ) 

else 

if ?f irstchoice = '6.0 SAFETY DATA REQUIREMENTS FOR NEW MISSIONS' 
then 

do ('6.0 SAFETY DATA REQUIREMENTS FOR NEW MISSIONS') 

else 

if ?firstchoice = 

'7.0 SAFETY DATA REQUIREMENTS FOR STANDARD ELEMENT MISSIONS' 

then 

do ('7.0 SAFETY DATA REQUIREMENTS FOR STANDARD ELEMENT MISSIONS') . 


topic '1.0 PURPOSE', 
column = ?column + 1. 
row = ?row + 1. 

window ('1.0 PURPOSE' , blue, white, white, ?column, ?row, 74, 18) . 
say ( ' 

The purpose of this document is to delineate the activities and 
documentation requirements leading to safety certification of 
instruments, facilities, Mission-Peculiar Equipment (MPE) , and 
Instrument Ground Support Equipment (IGSE) that constitute a 
National Space Transportation System (NSTS) payload or payload 
complement for which the #mPPO#m has management and integration 
responsibility. These requirements and activities are commensurate 
with and issued to implement : 

NHB 1700 . 7 , "Safety Policy and Requirements for Payloads Using the NSTS"; 
KHB 1700.7, "NSTS Ground Safety Handbook"; and 

NSTS 13830 , "Implementation Procedure for NSTS Payload Systems Safety 
Requirements . " 

♦Documentation references apply to current issue and/or revision and 
all approved changes of the referenced document. 

Press #fyellow SPACE#d to continue . ' ) . 
column = ? column - 1. 
row = ?row - 1. 
close_window () . 
end. (*1. PURPOSE*) 

topic '2.0 SCOPE', 
column = ?column + 1. 
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row = ? row + 1 . 

window ('2.0 SCOPE' ,blue, white, white, ?column, ?row, 74, 19) . 
say ( ' 

This document designates the safety-related activities and 
documentation required of individual #mPED#ms . The Payload Mission 
Manager (PMM) activities are outlined and discussed only to the 
extent necessary for clarification of the overall systems safety 
program activities. 

This document is applicable to all Marshall Space Flight Center 
(MSFC) #mPPO#m managed #mSTS#m attached payload missions and to all of the 
PEDs for those missions. STS attached payloads include Spacelab 
dedicated missions, middeck payloads, and partial -payload missions. 

A partial -payload mission is a flight that is not a Spacelab-dedicated 
(unique) mission and is shared with other payloads. Such missions are 
also referred to as mixed cargo missions. 

Partial payloads are defined as those payloads that do not require 
a Spacelab module or the Spacelab igloo. 

Press #fyellow SPACE#d to continue . ' ) . 
column = ? column - 1. 
row = ?row - 1 . 
close_window ( ) . 
end. ( *2 . SCOPE*) 

topic '3.0 GENERAL', 
column = ? column + 1. 
row = ?row + 1 . 

window ('3.0 GENERAL' , blue, white, white, ?column, ?row, 74, 18) . 
say (' 

There are two distinct aspects of the payload systems safety program. 

These are : 

1. The Individual Payload Element. Certifying that each item of 
payload equipment, including ground support equipment (GSE) , is 
safe for flight/ground operations. 

2. The Integrated Payload. Certifying that the payload elements, 
when combined into an integrated payload (IPL) , including GSE, 
are safe for flight and ground operations. 

The analysis/data and documentation submittal cycles designated 
herein are required to accomplish this certification process. 

All activities required for payload element equipment and operations 
safety certification are the responsibility of the #mPED#m. All PEDs are 
required to certify the safety of their individual payload elements to 
the #mPMM#m . 

The PMM is responsible for certifying the safety of the #mIPL#m to the #mSTS# 
Operators [Johnson Space Center (JSC) and Kennedy Space Center (KSC) ] . 

A series of progressive reviews, scaled to the maturity of the 
hardware, are scheduled during the Payload Element /Mission Development 
activity. These are necessary to ensure that the final delivered payload 
elements are safe and acceptable for ground processing and flight. 

It is the PED ' ' s responsibility to evaluate the design and operation of 
the payload element; identify, document, and control potential hazards ,- 
and verify the hazard controls of the payload element. These tasks are 
documented in a #mPED#m Safety Compliance Data Package and are reviewed by 
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the #mPMM#m to ensure overall payload safety. The PED''s safety data submit- 
tals are incorporated into Integrated Payload Safety Compliance Data 
which are reviewed as part of the PMM #mIPL#m reviews, updated as a result 
of the reviews, and used for the safety reviews with the #mNSTS#m operators. 

Press #fyellow SPACE#d to continue.'), 
column = ?column - 1. 
row = ?row - 1. 
close_window () . 
end. ( *3 . GENERAL*) 


topic '4.0 APPLICABLE DOCUMENTS', 
column = ?column + 1. 
row = ?row + 1. 

window ('4. APPLICABLE DOCUMENTS' , blue, white , white , ?column, ?row, 74 , 17) . 
say ( ' No revision letters/numbers are designated since all references are 
to the latest revision of the document including all approved changes . 


NHB 1700.7 
KHB 1700.7 
NSTS 18798 

JA-447 
JA-061 
JA-081 
JA-276 
NSTS 13830 


Safety Policy and Requirements for Payloads Using 
the Space Transportation System (STS) 

Space Transportation System Payload Ground 
Safety Handbook 

Interpretations of STS Payload Safety Requirements 
(Which contains JSC Letter TA-87-079, "Resumption 
of Payload Safety Activity, " a mandatory 
requirements letter) 

Mission Requirements on Facilities/Instruments/ 
Experiments for Space Transportation Systems 
(STS) Attached Payloads (MROFIE) 

Payload Mission Manager Interface and Safety 
Verification Requirements for Instruments, Facilities, 
MPE, and ECE on STS Spacelab Payload Missions 

Payload Mission Manager Interface and Safety 
Verification Requirements for Instruments, Facilities, 
MPE, and ECE on STS Partial Payload Missions 

Payload Mission Manager Interface and Safety 
Verification Requirements for Instruments, Facilities, 
MPE, and ECE on STS Orbiter Middeck Payload Missions 

Implementation Procedure for NSTS Payloads System 
Safety Requirements 


JSC 11123 

KHB 1860.1 
KHB 1860.2 
JA-418 

MSFC-PROC-1301 


STS Payload Safety Guidelines Handbook 
(Guidelines Only) 

KSC Radiation Protection Handbook 

KSC Non-Ionizing Radiation Protection Program 

Payload Flight Equipment Requirements for Safety 
Critical Structures 

Guidelines for the Implementation of Required 
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Materials Control Procedures 

SPAH SLP/2104 Spacelab Payload Accommodation Handbook 

I CD 2-1 M001 Orbiter Middeck/Payload Standard Interfaces Control 

Document 


I CD 2-1-19001 Shuttle Orbiter/Cargo Standard Interfaces 

(Attachment 1 to NSTS 07700, Volume XIV) 

NOTE: The Level I payload flight safety requirements document, 

NHB 1700.7, is currently undergoing revision. JSC Letter TA-87-079 
outlines mandatory additional requirements that must be implemented 
by the PED, pending release of the revised Level I document. These 
include certain unique safety data submittal requirements beyond 
those defined here in Section 6.0, SAFETY DATA REQUIREMENTS FOR NEW 
MISSIONS. Particular attention should be given to Paragraph c and 
Enclosure 2 of TA-87-079 relative to data submittals. 


Press #fyellow SPACE#d to continue.'), 
column = ? column - 1 . 
row = ?row - 1 . 
close_window ( ) . 

end. ( *4 . APPLICABLE DOCUMENTS*) 

topic '5.0 IMPLEMENTATION APPROACH' . 
column = ? column + 1 . 
row = ?row + l. 

window ('5.0 IMPLEMENTATION APPROACH' , blue , white, white, ?column, ?row, 74 , 17) . 
say ( ' 

The objective of the Safety Program is to protect flight and ground 
personnel, the #mSTS#m, Spacelab, #mGSE#m, the general public, public-private 
property, and the environment from payload-related hazards. As defined 
in #mNHB 1700. 7#m, a hazard is "the presence of a potential risk situation 
caused by an unsafe act or condition." 

Simply put, safety assurance consists of the following three steps: 

1. Hazard Identification - This is the result of a "Hazard Analysis" 
in which the Payload flight and ground support equipment, 

along with its attendant flight and ground operations, are 
analyzed to determine potential hazards. 

2 . Hazard Control - The method in the design by which the 
hazard is controlled and/or eliminated. In certain cases this 
may be accomplished by operating procedures. 

3. Hazard Control Verification - Demonstration by test, and/or 
analysis, and/or inspection that the hazard control method 
performs to specifications and does, indeed, control and/or 
eliminate the hazard. 

The data/ informat ion from these steps are documented in "Hazard 
Reports" and supporting data which are required submissions at 
appropriate Payload/Program Reviews. These reviews are: 

*The #mPED#m Payload Element Reviews and the #mPMM#m Integrated Payload 

(IPL) Reviews which are described in Section 4 . 0 of #mJA-447#m. 
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*The Phase 0, I, II, and III Safety Reviews conducted with the #mNSTS#m 
Operators which are described in Section 5.0 of #mNSTS 13830#m. The PMM 
assesses/incorporates the PED safety data given at the PED reviews 
into an overall Integrated Payload Safety Compliance Data Package 
which the PMM presents to the NSTS Safety Panels. The PED is 
encouraged (and in most cases will be required) to participate in 
these Safety Panel reviews. 

The relationship of the PED and #mIPL#m reviews to the #mPED#m design, safety 
implementation and verification activities is shown in #mFigure 5-1 Phase 0#m. 
The indicated flight and ground safety data is described in more detail 
in Section 6.0 SAFETY DATA REQUIREMENTS FOR NEW MISSIONS and also in 
Section 7.0 SAFETY DATA REQUIREMENTS FOR STANDARD ELEMENT MISSIONS, and 
its flow in relation to program milestones is depicted in Figure 6-1. 

These safety data must be in sufficient detail to describe the equipment 
and its operation and to define the potential hazards and the proposed 
or implemented hazard control methods. A hazards analysis is required on 
all f light/ground hardware, operations, and software, as applicable. 

These data also form the basis for the Phase 0, I, II, III integrated 
safety reviews required by the #mNSTS#m Operators . 


In some cases, depending upon payload design maturity. Phase 0 and 
Phase I may be combined into a single review, at the discretion of 
the #mPMM#m. The integrated payload safety reviews conducted for the 
#mNSTS#m Operators are generally scheduled 10 weeks after the PMM''s 
integrated payload reviews. Ensuring the safety of the payload is 
the primary objective of the reviews. The safety compliance data 
packages consist of the Hazard Reports (HRs) with their supporting 
data and the other mandatory data such as the equipment descriptions 
and operations and the hazardous subsystem descriptions. The Payload 
Safety Compliance Data Packages are vital in transmitting to the 
reviewers an understanding of the equipment, of the hazards involved, 
of the validity of the approach to hazards control, and verification 
that the controls have been implemented and proven effective. 


As shown in #mFigure 5-1 Phase 0#m, the initial safety assessment is of 
the conceptual design of the flight /ground hardware. This is Phase 0 
safety data which is generated for the #mPED#m Preliminary Requirements 
Review (PRR) and then combined with the other payload element safety 
data in an integrated payload safety data package for review at the 
#mIPL#m Requirements Review (RR) . After resolution of discrepancies it 
will be taken, if required, by the #mPMM#m to the #mNSTS#m safety review 
panels for a Phase 0 review. 

Both ground and flight safety hazards analyses, at the preliminary 
design level, are required for the Phase I ground and flight safety 
data package due at #mPED#m #mPDR#m. Also due at PED PDR is a preliminary 
version of the PED Verification Plan which includes descriptions of 
the activities and the plan for verifying the hazard controls. The 
applicable data are summarized in the #mHR#ms which are assessed by the 
#mPMM#m, combined into an #mIPL#m Safety Compliance Data Pack at the IPL PDR, 
and then presented to the #mNSTS#m Safety Panels at the Phase I review. 


The next safety data iteration is at the final design level. This 
is the Critical Design Review (CDR) and is a review of the design to 
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which the flight and ground hardware /software is to be manufactured. 
Thus, the finalization of the hardware description and operation, the 
hazard controls, and the verifiction methods to be implemented in 
verifying those controls are in the #mPED#m CDR data package . The PED 
Safety Compliance Data is assessed and combined by the PMM into an 
#mIPL#m Safety Compliance Data Package which is baselined following the 
IPL CDR, with the signature of each of the PEDs required. Once 
baselined, the data/documents come under control of the Payload 
Mission Manager (PMM) Configuration Control Board (CCB) and any 
subsequent changes are formally controlled. It is the responsibility 
of the PED to ensure that his data remains current and accurate. 


Data/documentation changes resulting from mandatory modifications, 
closeouts, or other review actions are incorporated into the safety 
data package by the submission of an Engineering Change Request (ECR) 
by the #mPED#m and approval of the ECR by the #mPMM#m chaired #mCCB#m. 

(Note: Change request preparation and processing is described in 
Appendix F of #mJA-447#m, MROFIE) . 

After #mIPL#m #mCDR#m, the PMM delivers the baselined #mIPL#m Safety Complia 
Data Package to the NSTS Phase II Safety Review Panels for the Phase 
II safety reviews. Actions and open items arising from the Phase II 
panel review are then addressed and suitable actions are assigned for 
resolution. The PED remains responsible for the safety of his Payload 
Element (PE) . He must demonstrate satisfactory completion of hazard 
control verification and must be responsive to any safety mandated 
action, with respect to his equipment, arising from the successive 
reviews . 


The purpose of the Phase III safety review is to obtain Safety 
Panel approval of the completed safety analysis and of the safety 
certification data. The #mPED#m must submit data before the PED 
Integration Readiness Review (PED IRR) , which confirms the satisfactory 
completion of all hazard control verification items and of all open 
safety items . These data are submitted by the PED in the form of 
requested changes as #mECR#ms to the PED''s section of the baselined #mIPL#m 
Safety Compliance Data Package. The #mPMM#m will assess these data for 
technical adequacy, completeness, and compliance of the flight and 
ground hardware/software with the applicable #mNSTS#m safety requirements. 


Upon his approval of the #mECR#ms, the #mPMM#m will make the appropriate 
changes in the #mIPL#m Safety Compliance Data Package then he will initiate 
and maintain the Payload Flight Safety Verification Tracking Log to 
formally document and status the payload verification work that was not 
completed at the time of preparation of the Phase III data package. 

The PMM will then present the data contained in the safety analyses and 
the Verification Log to the Safety Panels. He will place special 
emphasis on all changes made since the Phase II review, on the status 
of any open actions, and in particular he will address satisfactory 
completion of all open hazard control verifications. He will also 
present his required final assessment of the as-built payload/#mGSE#m 
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against the applicable safety requirements . 


A delta Phase III Flight Safety Review will be conducted for all 
payloads at Launch minus 2 months (L-2 mo) . No change in #mPED#m hardware/ 
software/operations is permitted following the original Phase III 
review unless the intended change is formally approved by the #mPMM#m 
before its incorporation. Should the proposed change be planned before 
on-line operations at #mKSC#m, PMM approval is sought through formal 
submission by the PED of an #mECR#m to the PMM Configuration Control Board. 

Once on-line activities are underway at KSC, changes to hardware/ 
software/operations may become necessary because of problems arising 
in the physical integration, test, and checkout of the Payload Element. 

Changes necessitated by these on-line activities become part of the KSC 
problem reports/closeouts in the appropriate KSC procedures, and the 
submission of an ECR is not required. However, these changes will be 
reviewed and assessed for safety impacts by the PMM in preparation for 
the delta Phase III Flight Safety Review. Also, the PED will 
participate in the closing of all applicable problem reports. 

Safety certification will be given only after the satisfactory 
completion of all of the required verification activity. 

Early identification of potential flight and ground hazards is 
necessary to ensure that controls are implemented in the design and 
that the proper hazard control verification is incorporated in the PED 
Verification Plan (defined in Appendix B of #mJA-447#m) . Based on results 
of #mPED#m, #mIPL#m, and #mNSTS#m safety reviews, additional safety verificati 
data may be required during the course of the hardware program. The 
complexity of some instruments/experiments, coupled with their 
associated failure severity, requires significant insight into the 
systems/operations used to control catastrophic hazards. A Failure 
Mode and Effects Analysis (FMEA) serves as a useful tool for 
evaluating and assessing the independence of required redundant hazard 
controls for complex systems requiring two-failure tolerance (fail-safe, 
fail-safe systems) . 


The #mPED#m should assess his experiment hardware/software/operations 
and identify potential hazards that, based upon his judgement, require 
an #mFMEA#m to clearly demonstrate the required hazard control redundancy. 
The final FMEA "minimum" requirement will be based upon #mPMM#m assessment 
of the safety compliance data package with its Hazard Reports. 

Additional FMEAs may be required by the. PMM to show redundancy of 
hazard controls for catastrophic hazards. The PED safety compliance 
data are an integral part of the #mIPL#m safety data, with the individual 
Payload Element reports being integrated as sections into the overall 
IPL Safety Compliance Data Package, which is baselined at IPL #mCDR#m. In 
addition to the PED safety compliance data, the IPL Safety Compliance 
Data Package contains #mMPE#m and IPL safety assessments . 


During the course of resolving hazards associated with earlier 
payload missions, several hazards were identified as common to most 
payload elements. These hazards have been designated as "generic" 
hazards (see Appendix B) and can be used by the #mPED#m as guidelines if 
they are applicable to his equipment. The use of generic hazard reports 
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is not mandatory; however, the PED is required to identify all hazards, 
establish and verify controls, and document the results of hazard 
analyses. The results can be documented on unique reports. The use of 
generic hazard reports is encouraged since they provide appropriate 
documentation and identify suitable controls and their verifications. 

If the generic hazard reports are used, the PED should carefully 
evaluate whether the controls and verifications are applicable and 
adequate for his specific situation and modify the information 
accordingly. The generic hazard reports and information on backup data 
required are presented in Appendix B. The generic reports include both 
flight and ground hazards. 

To further assist the #mPED#m in developing hazard reports, examples of 
some unique hazard reports (that is, hazards unique to the payload 
element) have been included in Appendix C. These reports show the type 
and depth of information required, including the hazard controls. 

The actual control approach will be determined by the PED. These 
examples are provided as information only and should not be considered 
a compendium of all hazards associated with a payload. 


Press #fyellow SPACE#d to continue.'), 
column = ?column - 1. 
row = ?row - 1. 
close_window () . 

end. ( *5 . IMPLEMENTATION APPROACH*) 

topic '6.0 SAFETY DATA REQUIREMENTS FOR NEW MISSIONS', 
column = ?column + 1. 
row = ?row + 1. 

window ('6.0 SAFETY DATA REQUIREMENTS FOR NEW MISSIONS ' , blue , white , white , 
?column, ?row, 74,16) . 
say ( ' 

Minimum requirements for the content of flight and ground safety 
compliance data packages have been established and documented in 
#mNSTS 13830#m, the implementing procedure for #mNHB 1700. 7#m and #mKHB 1700. 
Safety data required from the #mPED#m is depicted in the Payload Safety 
Compliance Documentation Flow of #mFigure 6-l#m, with corresponding 
submittal time requirements given in tmTable 6-l#m. Specific details of 
the data shown are given in this section. 

In developing the safety data in compliance with implementation 
requirements, it is necessary that each hazard report stand alone 
(i.e., all information/data necessary to fully explain/describe the 
hazard causes and controls must be incorporated into or attached to 
the hazard report) . Reference to other documents may not be used in 
lieu of presenting the necessary information and supporting data. 


Reference to known standards (i.e., #mMSFC-SPEC-522#m, #mMIL-B-5087#m, 
#mNHB 8060. l#m, etc .) is acceptable, however, in the hazard control 
statements. Safety data will ultimately be reviewed by #mNSTS#m design 
and safety organizations who do not have access to the payload 
element design review packages. This necessitates that hazard reports 
must stand alone and be supported with sufficient information, 
including simplified drawings, sketches, and schematics. This allows 
for assessment of the hazard, cause, controls, specific verification 
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methods, and status of hazard control verification. The degree of 
supporting information required is based on the payload element design 
complexity, the maturity of the payload element development, and the 
safety review phase. 


This section of the program provides information and instructions for 
the PED to follow to develop both the Flight Safety Compliance Data 
Package, the Ground Safety Compliace Data, and the PMM Activities 
for each Phase 0, Phase I, Phase II, Phase III and Delta Phase III. 


Press #fyellow SPACE#d to continue.') . 


topic 'Table 6-1' . 

column = ? column + 1. 
row = ?row + 1 . 

window ('Table 6-1 ' ,blue, white, white, ?column, ?row, 72 , 18) . 
say (' PED SAFETY COMPLIANCE DATA PACKAGE SUBMITTAL REQUIREMENTS 

PED DATA PACKAGE SUBMITTAL UPDATED PACKAGE 

REQUIREMENT per RlDs/DNs 


FLIGHT SAFETY DATA 


Phase 

0 

PED PRR 

-30 

days 

PED 

PRR 

+30 

days 

Phase 

I 

PED PDR 

-30 

days 

PED 

PDR 

+30 

days 

Phase 

II 

PED CDR 

-30 

days 

PED 

CDR 

+30 

days 

Phase 

III 

PED IRR 

-30 

days 





Delta 

Phase III 

Launch 

- 2 

months 





GROUND SAFETY DATA 








Phase 

0 

PED PRR 

-30 

days 

PED 

PRR 

+30 

days 

Phase 

I 

PED PDR 

-30 

days 

PED 

PDR 

+3 0 

days 

Phase 

II 

PED CDR 

-30 

days 

PED 

CDR 

+30 

days 

Phase 

III 

PED IRR 

-90 

days 






Press #fyellow SPACE#d to continue. ') . 


column = ?column - 1 . 
row = ?row - 1. 
close_window () . 
end. (*Table 6-1*) 

column = ?column - 1 . 
row = ?row - 1. 
close_window ( ) . 

end. ( *6 . SAFETY DATA REQUIREMENTS FOR NEW MISSIONS*) 

topic '7.0 SAFETY DATA REQUIREMENTS FOR STANDARD ELEMENT MISSIONS' . 
column = ? column + 1 . 
row = ?row + 1 . 

window ('7.0 SAFETY DATA REQUIREMENTS FOR STANDARD ELEMENT MISSIONS ', blue, 
white, white, ?column, ?row, 74,16) . 
say ( ' #e 
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Standard Elements are those elements that have successfully completed 
the #mNSTS#m payload safety review process . Standard elements are : 

Previously flown hardware that is to be reflown or Ground Support 
Equipment which has completed the safety review process. 

Series hardware (hardware in a series that is identical in design 
to hardware previously flown, or qualified ground hardware) . 

Special data submittal requirements have been developed for payloads 
using standard elements to eliminate unnecessary duplication of 
safety activities. The data flow from Payload Element #mPED#m to 
Integrated Payload #mPMM#m to #mNSTS#m Phased Safety reviews remains the 
same as that depicted in #mFigure 5-l#m and #mFigure 6-l#m. 


This section defines the specific safety assurance data requirements 
for standard elements in both the Safety Compliance Data Package 
and the PMM Activities. 


Press #fyellow SPACE#d to continue.'), 
column = ? column - 1. 
row = ?row - 1 . 
close_window () . 

end. ( *7 . SAFETY DATA REQUIREMENTS FOR STANDARD ELEMENT MISSIONS*) 
(♦created 1/24/94*) 
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(*SAFJA012 . KB This is the beginning of the Safety Compliance Data Package*) 
eof = number_to_char (26) . 
column = 3 . 
row = 3 . 

do (Safety_Compliance_Data_Package) . 

topic mark (f ind_string) . 
row = ?row + 1 . 
column = ?column + 1. 

text is read ('NASATERM.DAT', concat ('//', ?find_string) , '/end'), 
window (?find_string, blue, white, white, ?column, ?row, 72,12). 
say (?text) . 
close_window ( ) . 
row = ?row - 1 . 
column = ?column - 1. 
end. (*topic mark*) 

topic ' Safety_Compliance_Data_Package ' . 
firstchoice = ' ' . 
list first = ['1.0 PURPOSE', 

'2.0 SCOPE', 

'3.0 GENERAL', 

'4.0 APPLICABLE DOCUMENTS' , 

'5.0 IMPLEMENTATION APPROACH' , 

'6.0 SAFETY DATA REQUIREMENTS FOR NEW MISSIONS', 

'7.0 SAFETY DATA REQUIREMENTS FOR STANDARD ELEMENT MISSIONS', 
'QUIT' ] . 

window ('PPO Payload Safety Implementation Approach' , blue, white, white, 
?column, ?row, 76 , 17) . 
while ?firstchoice <> 'QUIT' 
then 

ask ( ' #e 

The JA-012 PPO Payload Safety Implementation Approach Document 
provides information to the PEDs about their responisbilities 
for documenting the tasks required to evaluate the design and 
operation of the payload element. This documentation is recorded 
in the PED Safety Compliance Data Package. 

JA-012 covers these areas: ', firstchoice, ?list first ) 

and 

if ?f irstchoice = 'QUIT' 
then 

new_kb ( ' SAF12MEN . HKB ' ) 

else 

if ? firstchoice = '1.0 PURPOSE' 
then 

do ('1.0 PURPOSE ' ) 

else 

if Tfirstchoice = '2.0 SCOPE' 
then 

do ('2.0 SCOPE') 

else 

if ?f irstchoice = '3.0 GENERAL' 
then 

do ('3.0 GENERAL') 

else 

if ?f irstchoice = '4.0 APPLICABLE DOCUMENTS' 
then 

do ('4.0 APPLICABLE DOCUMENTS' ) 
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else 

if ?f irstchoice = '5.0 IMPLEMENTATION APPROACH' 
then 

do ('5.0 IMPLEMENTATION APPROACH' ) 

else 

if ?f irstchoice = '6.0 SAFETY DATA REQUIREMENTS FOR NEW MISSIONS' 
then 

do ('6.0 SAFETY DATA REQUIREMENTS FOR NEW MISSIONS') 

else 

if ?firstchoice = 

'7.0 SAFETY DATA REQUIREMENTS FOR STANDARD ELEMENT MISSIONS' 

then 

do ('7.0 SAFETY DATA REQUIREMENTS FOR STANDARD ELEMENT MISSIONS'). 


topic '1.0 PURPOSE', 
column = ?column + 1. 
row = ?row + 1. 

window ('1.0 PURPOSE' , blue, white, white, ?column, ?row, 74 , 18) . 
say (' 

The purpose of this document is to delineate the activities and 
documentation requirements leading to safety certification of 
instruments, facilities, Mission-Peculiar Equipment (MPE) , and 
Instrument Ground Support Equipment (IGSE) that constitute a 
National Space Transportation System (NSTS) payload or payload 
complement for which the #mPPO#m has management and integration 
responsibility. These requirements and activities are commensurate 
with and issued to implement : 

NHB 1700 . 7, "Safety Policy and Requirements for Payloads Using the NSTS"; 
KHB 1700.7, "NSTS Ground Safety Handbook"; and 

NSTS 13830, "Implementation Procedure for NSTS Payload Systems Safety 
Requirements . " 

♦Documentation references apply to current issue and/or revision and 
all approved changes of the referenced document . 

Press #fyellow SPACE#d to continue.'), 
column = ? column - 1. 
row = ?row - 1. 
close_window () . 
end. (*1. PURPOSE*) 

topic '2.0 SCOPE', 
column = ? column + 1. 
row = ?row + 1. 

window ('2.0 SCOPE' , blue, white, white, ?column, ?row, 74 , 19) . 
say ( ' 

This document designates the safety-related activities and 
documentation required of individual #mPED#ms. The Payload Mission 
Manager (PMM) activities are outlined and discussed only to the 
extent necessary for clarification of the overall systems safety 
program activities. 

This document is applicable to all Marshall Space Flight Center 
(MSFC) #mPPO#m managed #mSTS#m attached payload missions and to all of the 
PEDs for those missions. STS attached payloads include Spacelab 
dedicated missions, middeck payloads, and partial -payload missions. 

A partial -payload mission is a flight that is not a Spacelab-dedicated 
(unique) mission and is shared with other payloads. Such missions are 
also referred to as mixed cargo missions . 
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Partial payloads are defined as those payloads that do not require 
a Spacelab module or the Spacelab igloo. 

Press #fyellow SPACE#d to continue.'), 
column = ?column - 1. 
row = ?row - 1. 
close_window () . 
end. (*2. SCOPE*) 

topic '3.0 GENERAL', 
column = ? column + 1. 
row = ?row + 1. 

window ('3.0 GENERAL' ,blue, white, white, ?column, ?row, 74, 18) . 
say ( ' 

There are two distinct aspects of the payload systems safety program. 

These are : 

1 . The Individual Payload Element . Certifying that each item of 
payload equipment, including ground support equipment (GSE) , is 
safe for flight/ground operations. 

2. The Integrated Payload. Certifying that the payload elements, 
when combined into an integrated payload (IPL) , including GSE, 
are safe for flight and ground operations. 

The analysis/data and documentation submittal cycles designated 
herein are required to accomplish this certification process. 

All activities required for payload element equipment and operations 
safety certification are the responsibility of the #mPED#m. All PEDs are 
required to certify the safety of their individual payload elements to 
the #mPMM#m. 

The PMM is responsible for certifying the safety of the #mIPL#m to the #mSTS# 
Operators [Johnson Space Center (JSC) and Kennedy Space Center (KSC) ] . 

A series of progressive reviews, scaled to the maturity of the 
hardware, are scheduled during the Payload Element/Mission Development 
activity. These are necessary to ensure that the final delivered payload 
elements are safe and acceptable for ground processing and flight. 

It is the PED''s responsibility to evaluate the design and operation of 
the payload element; identify, document, and control potential hazards; 
and verify the hazard controls of the payload element . These tasks are 
documented in a #mPED#m Safety Compliance Data Package and are reviewed by 
the #mPMM#m to ensure overall payload safety. The PED''s safety data submit- 
tals are incorporated into Integrated Payload Safety Compliance Data 
which are reviewed as part of the PMM #mIPL#m reviews, updated as a result 
of the reviews, and used for the safety reviews with the #mNSTS#m operators. 

Press #f yellow SPACE#d to continue.'), 
column = ? column - 1 . 
row = ?row - 1 . 
close_window () . 
end. (*3 . GENERAL*) 

topic '4.0 APPLICABLE DOCUMENTS', 
column = ? column + 1 . 
row = ?row + 1 . 

window ('4. APPLICABLE DOCUMENTS' , blue , white , white, ?column, ?row, 74 , 17) . 
say (' No revision letters/numbers are designated since all references are 
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to the latest revision of the document including all approved changes. 


NHB 1700.7 
KHB 1700.7 
NSTS 18798 

JA-447 
JA- 061 
JA- 081 
JA-276 
NSTS 13830 


Safety Policy and Requirements for Payloads Using 
the Space Transportation System (STS) 

Space Transportation System Payload Ground 
Safety Handbook 

Interpretations of STS Payload Safety Requirements 
(Which contains JSC Letter TA-87-079, "Resumption 
of Payload Safety Activity, " a mandatory 
requirements letter) 

Mission Requirements on Facilities/Instruments/ 
Experiments for Space Transportation Systems 
(STS) Attached Payloads (MROFIE) 

Payload Mission Manager Interface and Safety 
Verification Requirements for Instruments, Facilities, 
MPE, and ECE on STS Spacelab Payload Missions 

Payload Mission Manager Interface and Safety 
Verification Requirements for Instruments, Facilities, 
MPE, and ECE on STS Partial Payload Missions 

Payload Mission Manager Interface and Safety 
Verification Requirements for Instruments, Facilities, 
MPE, and ECE on STS Orbiter Middeck Payload Missions 

Implementation Procedure for NSTS Payloads System 
Safety Requirements 


JSC 11123 

KHB 1860.1 
KHB 1860.2 
JA-418 

MSFC-PROC-1301 

SPAH SLP/2104 
I CD 2-1 M001 


STS Payload Safety Guidelines Handbook 
(Guidelines Only) 

KSC Radiation Protection Handbook 

KSC Non- Ionizing Radiation Protection Program 

Payload Flight Equipment Requirements for Safety 
Critical Structures 

Guidelines for the Implementation of Required 
Materials Control Procedures 

Spacelab Payload Accommodation Handbook 

Orbiter Middeck/Payload Standard Interfaces Control 
Document 


I CD 2-1-19001 Shuttle Orbiter/Cargo Standard Interfaces 

(Attachment 1 to NSTS 07700, Volume XIV) 

NOTE: The Level I payload flight safety requirements document, 

NHB 1700.7, is currently undergoing revision. JSC Letter TA-87-079 
outlines mandatory additional requirements that must be implemented 
by the PED, pending release of the revised Level I document. These 
include certain unique safety data submittal requirements beyond 
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those defined here in Section 6.0, SAFETY DATA REQUIREMENTS FOR NEW 
MISSIONS. Particular attention should be given to Paragraph c and 
Enclosure 2 of TA-87-079 relative to data submittals. 


Press #fyellow SPACE#d to continue.'), 
column = ?column - 1. 
row = ?row - 1 . 
close_window {) . 

end. ( *4 . APPLICABLE DOCUMENTS*) 

topic '5.0 IMPLEMENTATION APPROACH' . 
new_kb ( ' SEC5 SUB . HKB ' ) . 

end. (*5 . IMPLEMENTATION APPROACH*) 

topic '6.0 SAFETY DATA REQUIREMENTS FOR NEW MISSIONS', 
column = ?column + 1. 
row = ?row + 1. 

window ('6.0 SAFETY DATA REQUIREMENTS FOR NEW MISSIONS' , blue, white, white, 
?column, ?row, 74 , 17) . 
say ( ' 

Minimum requirements for the content of flight and ground safety 
compliance data packages have been established and documented in 
#mNSTS 13830#m, the implementing procedure for #mNHB 1700. 7#m and #mKHB 1700 
Safety data required from the #mPED#m is depicted in the Payload Safety 
Compliance Documentation Flow of #mFigure 6-l#m, with corresponding 
submittal time requirements given in #mTable 6-l#m. Specific details of 
the data shown are given in this section. 

In developing the safety data in compliance with implementation 
requirements, it is necessary that each hazard report stand alone 
(i.e., all informat ion/data necessary to fully explain/describe the 
hazard causes and controls must be incorporated into or attached to 
the hazard report) . Reference to other documents may not be used in 
lieu of presenting the necessary information and supporting data. 


Reference to known standards (i.e., #mMSFC-SPEC-522#m, #mMIL-B-5087#m, 
#mNHB 8060. l#m, etc .) is acceptable, however, in the hazard control 
statements. Safety data will ultimately be reviewed by #mNSTS#m design 
and safety organizations who do not have access to the payload 
element design review packages. This necessitates that hazard reports 
must stand alone and be supported with sufficient information, 
including simplified drawings, sketches, and schematics. This allows 
for assessment of the hazard, cause, controls, specific verification 
methods, and status of hazard control verification. The degree of 
supporting information required is based on the payload element design 
complexity, the maturity of the payload element development, and the 
safety review phase. 

Press tfyellow SPACEid to continue.'). 

(*This calls a subprogram that displays all of section 6.0.*) 

topic 'Table 6-1' . 

column = ? column + 1 . 
row = ?row + 1. 

window ('Table 6-1' , blue, white, white , ?column, ?row, 72 , 18) . 
say (' PED SAFETY COMPLIANCE DATA PACKAGE SUBMITTAL REQUIREMENTS 
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PED DATA PACKAGE 


SUBMITTAL 

REQUIREMENT 


UPDATED PACKAGE 
per RIDs/DNs 


FLIGHT SAFETY DATA 


Phase 

0 

PED PRR 

-30 

days 

PED 

PRR 

+30 

days 

Phase 

I 

PED PDR 

-30 

days 

PED 

PDR 

+ 30 

days 

Phase 

II 

PED CDR 

-30 

days 

PED 

CDR 

+ 30 

days 

Phase 

III 

PED IRR 

-30 

days 




Delta 

Phase III 

Launch 

- 2 

months 





GROUND SAFETY DATA 








Phase 

0 

PED PRR 

-30 

days 

PED 

PRR 

+ 30 

days 

Phase 

I 

PED PDR 

-30 

days 

PED 

PDR 

+30 

days 

Phase 

II 

PED CDR 

-30 

days 

PED 

CDR 

+ 30 

days 

Phase 

III 

PED IRR 

-90 

days 





Press #fyellow SPACE#d to continue. '). 


column = ? column - 1. 
row = ?row - 1 . 
close_window ( ) . 
end. (*Table 6-1*) 

new_kb ( ' SEC6SUB . HKB ' ) . 

column = ? column - 1. 
row = ?row - 1 . 
close_window ( ) . 

end. ( *6 . SAFETY DATA REQUIREMENTS FOR NEW MISSIONS*) 

topic '7.0 SAFETY DATA REQUIREMENTS FOR STANDARD ELEMENT MISSIONS' . 
column = ? column + 1. 
row = ?row + 1 . 

window ('7.0 SAFETY DATA REQUIREMENTS FOR STANDARD ELEMENT MISSIONS' , blue, 
white, white, ?column, ?row, 74, 16) . 
say ( ' #e 

Standard Elements are those elements that have successfully completed 
the #mNSTS#m payload safety review process. Standard elements are: 

Previously flown hardware that is to be reflown or Ground Support 
Equipment which has completed the safety review process. 

Series hardware (hardware in a series that is identical in design 
to hardware previously flown, or qualified ground hardware) . 

Special data submittal requirements have been developed for payloads 
using standard elements to eliminate unnecessary duplication of 
safety activities. The data flow from Payload Element #mPED#m to 
Integrated Payload #mPMM#m to #mNSTS#m Phased Safety reviews remains the 
same as that depicted in #mFigure 5-l#m and #mFigure 6-l#m. 

Press #fyellow SPACE#d to continue.') 

and 

do (sectionseven) . 
topic 'sectionseven'. 

Iist7 = ['7.1 SAFETY COMPLIANCE DATA REQUIREMENTS', 

'7.2 PMM ACTIVITIES' , 

'QUIT' ] . 
choice7 = ' ' . 
while ?choice7 <> 'QUIT' 


D-32 


then 
ask ( ' 

These sections define the specific safety assurance data requirements 
for standard elements. Please select the section you wish to continue 
with. ' , choice7, ?list7) 
and 

if ?choice7 = 'QUIT' 
then 

column = ?column - 1 
and 

row = ?row - 1 
and 

close_window ( ) 

else 

if ?choice7 = '7.1 SAFETY COMPLIANCE DATA REQUIREMENTS' 
then 

do ('7.1 SAFETY COMPLIANCE DATA REQUIREMENTS') 

else 

if ?choice7 = '7.2 PMM ACTIVITIES' 
then 

do ('7.2 PMM ACTIVITIES' ) . 

topic '7.1 SAFETY COMPLIANCE DATA REQUIREMENTS', 
column = ?column + 1 . 
row = ? row + 1 . 

window ('7.1 SAFETY COMPLIANCE DATA REQUIREMENTS ', blue , white , white , 
?column, ?row, 73 , 16) . 
say ( ' 

A payload may be composed of a combination of new payload elements 
and standard elements. In this event, the safety data for new payload 
elements will be provided in accordance with section 6 . 0 SAFETY DATA 
REQUIREMENTS FOR NEW MISSIONS. 

The following data for standard elements shall be included in the #MPED#M 
Safety Compliance Data Package: 

1) Baseline Safety Compliance Data Package previously approved for 
flight or ground use/operation and closures of Safety Panel action 
items. The package should be updated to clearly delineate 
information which is not applicable to the new payload. This data 
shall be submitted as a part of the review data package at the 
first PED milestone review. 


2) An assessment of the safety verification methods identified on 
the hazard reports contained in the baseline Safety Compliance Data 
Package. All the safety verification methods that are modified or 
that must be reverified shall be clearly identified. 

3) Descriptions of changes (if applicable) made to the design or 
operational procedures of the standard element . Changes to the 
ground operations scenario should also be provided. For reflown 
hardware, a description of all maintenance and/or refurbishment 
to be accomplished should also be included. 

4) Hazard reports, including supporting data as necessary, to 
address changes affecting the standard element and its interfaces. 
These hazard reports shall be prepared to the level of detail 
required by the review being conducted. 
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5) Assessment statement regarding safety deficiencies encountered 
during previous usages of the standard elements. The #mPED#m shall 
evaluate all failures and anomalies encountered during previous 
use of the standard elements on the #mNSTS#m, ensure that those 
failures and anomalies affecting safety have been corrected, 

and identify the corrective action (s) taken. 

6) Assessment of the standard element for limited-life items 
(reflown hardware or reused #mGSE#m only) in terms of remaining time 
/cycles left before exceeding design life time/cycles. 

The data shall be updated as necessary for each of the phased reviews. 
At the Phase III review, the data should show that the verification/ 
reverification process has been completed and that all hazard controls 
/verifications are closed. 


(Note: The Phase III Safety Compliance Data Package shall contain a 
signed Certificate of Safety Compliance.) 


Press #fyellow SPACE#d to continue.') . 

column = ?column - 1. 
row = ?row - 1 . 
close_window () . 

end. {*7.1 SAFETY COMPLIANCE DATA REQUIREMENTS*) 

topic '7.2 PMM ACTIVITIES' . 
column = ? column + 1 . 
row = ?row + 1 . 

window ('7.2 PMM ACTIVITIES' , blue, white, white, ?column, ?row, 73, 15) . 
say (' 


Review of #mPED#m flight and ground safety data, subsequent 
incorporation of these data into the #mIPL#m Safety Compliance 
Data Package, and review of the IPL safety data by the #mNSTS#m 
Safety Panels at #mJSC#m and #mKSC#m proceed as in new missions. 


Press #fyellow SPACE#d to continue.'). 

column = ?column - 1 . 
row = ?row - 1 . 
close_window ( ) . 
end. 1*7.2 PMM ACTIVITIES*) 
end. (*sectionseven*) 

end. ( *7 . SAFETY DATA REQUIREMENTS FOR STANDARD ELEMENT MISSIONS*) 

(♦created 6/30/92 - 7/1/92*) 

(♦edited 12/13/93 - *) 
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(*SEC5SUB.KB This is the program called from SAFJA012 . KB to display section 
5.0 IMPLEMENTATION APPROACH, due to the number of graphics and referenced 
documents this section must be a stand alone section to conserve memory.*) 

eof = number_to_char (26) . 
column = 3 . 
row = 3 . 

do ('5.0 IMPLEMENTATION APPROACH' ) . 
new_kb ( ' SAP JAO 12 . HKB ' ) . 

topic mark (f ind_string) . 
row = ?row + 1. 
column = ?column + 1. 

text is read ( ' NASATERM . DAT ' , concat ('//', ?find_string) , '/end'), 
window (?f ind_string, blue, white, white, ?column, ?row, 72,12). 
say (?text) . 
close_window () . 
row = ?row - 1. 
column = ? column - 1 . 
end. (*topic mark*) 

topic '5.0 IMPLEMENTATION APPROACH' . 

window ('SAFETY COMPLIANCE DATA PACKAGE' , blue, white, white, ?column, ?row, 76, 18) . 
column = ? column + 1 . 
row = ?row + 1. 

window ('5.0 IMPLEMENTATION APPROACH' , blue , white, white , ’column, ?row, 74 , 17) . 
say ( ' 

The objective of the Safety Program is to protect flight and ground 
personnel, the #mSTS#m, Spacelab, #mGSE#m, the general public, public -private 
property, and the environment from payload-related hazards. As defined 
in #mNHB 1700. 7#m, a hazard is "the presence of a potential risk situation 
• • caused by an unsafe act or condition." 

Simply put, safety assurance consists of the following three steps: 

1. Hazard Identification - This is the result of a "Hazard Analysis" 
in which the Payload flight and ground support equipment, 

along with its attendant flight and ground operations, are 
analyzed to determine potential hazards. 

2. Hazard Control - The method in the design by which the 
hazard is controlled and/or eliminated. In certain cases this 
may be accomplished by operating procedures. 

3. Hazard Control Verification - Demonstration by test, and/or 
analysis, and/or inspection that the hazard control method 
performs to specifications and does, indeed, control and/or 
eliminate the hazard. 

The data/information from these steps are documented in "Hazard 
Reports" and supporting data which are required submissions at 
appropriate Payload/Program Reviews . These reviews are : 

*The #mPED#m Payload Element Reviews and the #mPMM#m Integrated Payload 
(IPL) Reviews which are described in tmSection 4 . 0#m of #mJA-447#m. 

*The Phase 0, I, II, and III Safety Reviews conducted with the tmNSTStm 
Operators which are described in tmSection 5 . 0#m of #mNSTS 13830#m. The PMM 
assesses/incorporates the PED safety data given at the PED reviews 
into an overall Integrated Payload Safety Compliance Data Package 
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which the PMM presents to the NSTS Safety Panels. The PED is 
encouraged (and in most cases will be required) to participate in 
these Safety Panel reviews. 

The relationship of the PED and #mIPL#m reviews to the #mPED#m design, safety 
implementation and verification activities is shown in #mFigure 5-l#m. 

The indicated flight and ground safety data is described in more detail 
in Section 6.0 SAFETY DATA REQUIREMENTS FOR NEW MISSIONS and also in 
Section 7.0 SAFETY DATA REQUIREMENTS FOR STANDARD ELEMENT MISSIONS, and 
its flow in relation to program milestones is depicted in #mFigure 6-l#m. 

These safety data must be in sufficient detail to describe the equipment 
and its operation and to define the potential hazards and the proposed 
or implemented hazard control methods. A hazards analysis is required on 
all flight /ground hardware, operations, and software, as applicable. 

These data also form the basis for the Phase 0, I, II, III integrated 
safety reviews required by the #mNSTS#m Operators . 


In some cases, depending upon payload design maturity. Phase 0 and 
Phase I may be combined into a single review, at the discretion of 
the #mPMM#m. The integrated payload safety reviews conducted for the 
#mNSTS#m Operators are generally scheduled 10 weeks after the PMM' ' s 
integrated payload reviews. Ensuring the safety of the payload is 
the primary objective of the reviews. The safety compliance data 
packages consist of the Hazard Reports (HRs) with their supporting 
data and the other mandatory data such as the equipment descriptions 
and operations and the hazardous subsystem descriptions. The Payload 
Safety Compliance Data Packages are vital in transmitting to the 
reviewers an understanding of the equipment, of the hazards involved, 
of the validity of the approach to hazards control, and verification 
that the controls have been implemented and proven effective. 


As shown in #mFigure 5-l#m, the initial safety assessment is of 
the conceptual design of the f light/ground hardware. This is Phase 0 
safety data which is generated for the #mPED#m Preliminary Requirements 
Review (PRR) and then combined with the other payload element safety 
data in an integrated payload safety data package for review at the 
#mIPL#m Requirements Review (RR) . After resolution of discrepancies it 
will be taken, if required, by the #mPMM#m to the #mNSTS#m safety review 
panels for a Phase 0 review. 

Both ground and flight safety hazards analyses, at the preliminary 
design level, are required for the Phase I ground and flight safety 
data package due at #mPED#m #mPDR#m. Also due at PED PDR is a preliminary 
version of the PED Verification Plan which includes descriptions of 
the activities and the plan for verifying the hazard controls. The 
applicable data are summarized in the #mHR#ms which are assessed by the 
#mPMM#m, combined into an #mIPL#m Safety Compliance Data Pack at the IPL PDR, 
and then presented to the #mNSTS#m Safety Panels at the Phase I review. 


The next safety data iteration is at the final design level. This 
is the Critical Design Review (CDR) and is a review of the design to 
which the flight and ground hardware/software is to be manufactured. 
Thus, the finalization of the hardware description and operation, the 
hazard controls, and the verifiction methods to be implemented in 
verifying those controls are in the #mPED#m CDR data package. The PED 
Safety Compliance Data is assessed and combined by the PMM into an 
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#mIPL#m Safety Compliance Data Package which is baselined following the 
I PL CDR, with the signature of each of the PEDs required. Once 
baselined, the data/documents come under control of the Payload 
Mission Manager (PMM) Configuration Control Board (CCB) and any 
subsequent changes are formally controlled. It is the responsibility 
of the PED to ensure that his data remains current and accurate. 


Data/documentation changes resulting from mandatory modifications, 
closeouts, or other review actions are incorporated into the safety 
data package by the submission of an Engineering Change Request (ECR) 
by the #mPED#m and approval of the ECR by the #mPMM#m chaired #mCCB#m. 

(Note: Change request preparation and processing is described in 
imAppendix F#m of #mJA-447#m, MROFIE) . 

After #mIPL#m #mCDR#m, the PMM delivers the baselined #mIPL#m Safety Complia 
Data Package to the NSTS Phase II Safety Review Panels for the Phase 
II safety reviews. Actions and open items arising from the Phase II 
panel review are then addressed and suitable actions are assigned for 
resolution. The PED remains responsible for the safety of his Payload 
Element (PE) . He must demonstrate satisfactory completion of hazard 
control verification and must be responsive to any safety mandated 
action, with respect to his equipment, arising from the successive 
reviews . 


The purpose of the Phase III safety review is to obtain Safety 
Panel approval of the completed safety analysis and of the safety 
certification data. The #mPED#m must submit data before the PED 
Integration Readiness Review (PED IRR) , which confirms the satisfactory 
completion of all hazard control verification items and of all open 
safety items. These data are submitted by the PED in the form of 
requested changes as #mECR#ms to the PED''s section of the baselined #mIPL#m 
Safety Compliance Data Package. The #mPMM#m will assess these data for 
technical adequacy, completeness, and compliance of the flight and 
ground hardware /software with the applicable #mNSTS#m safety requirements. 


Upon his approval of the #mECR#ms, the #mPMM#m will make the appropriate 
changes in the #mIPL#m Safety Compliance Data Package then he will initiate 
and maintain the Payload Flight Safety Verification Tracking Log to 
formally document and status the payload verification work that was not 
completed at the time of preparation of the Phase III data package. 

The PMM will then present the data contained in the safety analyses and 
the Verification Log to the Safety Panels. He will place special 
emphasis on all changes made since the Phase II review, on the status 
of any open actions, and in particular he will address satisfactory 
completion of all open hazard control verifications. He will also 
present his required final assessment of the as-built payload/#mGSE#m 
against the applicable safety requirements. 


A delta Phase III Flight Safety Review will be conducted for all 


payloads at Launch minus 2 months (L-2 mo) . No change in #mPED#m hardware/ 
software/operations is permitted following the original Phase III 
review unless the intended change is formally approved by the #mPMM#m 
before its incorporation. Should the proposed change be planned before 
on-line operations at #mKSC#m, PMM approval is sought through formal 
submission by the PED of an #mECR#m to the PMM Configuration Control Board. 

Once on-line activities are underway at KSC, changes to hardware/ 
software/operations may become necessary because of problems arising 
in the physical integration, test, and checkout of the Payload Element. 

Changes necessitated by these on-line activities become part of the KSC 
problem reports/closeouts in the appropriate KSC procedures, and the 
submission of an ECR is not required. However, these changes will be 
reviewed and assessed for safety impacts by the PMM in preparation for 
the delta Phase III Flight Safety Review. Also, the PED will 
participate in the closing of all applicable problem reports. 

Safety certification will be given only after the satisfactory 
completion of all of the required verification activity. 

Early identification of potential flight and ground hazards is 
necessary to ensure that controls are implemented in the design and 
that the proper hazard control verification is incorporated in the PED 
Verification Plan (defined in #mAppendix B of JA-447#m) . Based on results 
of #mPED#m, #mIPL#m, and #mNSTS#m safety reviews, additional safety verificati 
data may be required during the course of the hardware program. The 
complexity of some instruments/experiments, coupled with their 
associated failure severity, requires significant insight into the 
systems/operations used to control catastrophic hazards. A Failure 
Mode and Effects Analysis (FMEA) serves as a useful tool for 
evaluating and assessing the independence of required redundant hazard 
controls for complex systems requiring two- failure tolerance (fail-safe, 
fail-safe systems) . 


The #mPED#m should assess his experiment hardware/sof tware/operations 
and identify potential hazards that, based upon his judgement, require 
an #mFMEA#m to clearly demonstrate the required hazard control redundancy. 
The final FMEA "minimum" requirement will be based upon #mPMM#m assessment 
of the safety compliance data package with its Hazard Reports. 

Additional FMEAs may be required by the PMM to show redundancy of 
hazard controls for catastrophic hazards. The PED safety compliance 
data are an integral part of the #mIPL#m safety data, with the individual 
Payload Element reports being integrated as sections into the overall 
I PL Safety Compliance Data Package, which is baselined at IPL #mCDR#m. In 
addition to the PED safety compliance data, the IPL Safety Compliance 
Data Package contains #mMPE#m and IPL safety assessments. 


During the course of resolving hazards associated with earlier 
payload missions, several hazards were identified as common to most 
payload elements. These hazards have been designated as "generic" 
hazards (see #mAppendix B#m) and can be used by the #mPED#m as guidelines if 
they are applicable to his equipment . The use of generic hazard reports 
is not mandatory; however, the PED is required to identify all hazards, 
establish and verify controls, and document the results of hazard 
analyses. The results can be documented on unique reports. The use of 
generic hazard reports is encouraged since they provide appropriate 
documentation and identify suitable controls and their verifications. 
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If the generic hazard reports are used, the PED should carefully 
evaluate whether the controls and verifications are applicable and 
adequate for his specific situation and modify the information 
accordingly. The generic hazard reports and information on backup data 
required are presented in Appendix B. The generic reports include both 
flight and ground hazards. 


To further assist the #mPED#m in developing hazard reports, examples of 
some unique hazard reports (that is, hazards unique to the payload 
element) have been included in #mAppendix C#m. These reports show the type 
and depth of information required, including the hazard controls. 

The actual control approach will be determined by the PED. These 
examples are provided as information only and should not be considered 
a compendium of all hazards associated with a payload. 


Press #fyellow SPACE#d to continue.') . 

column = ? column - 1. 
row = ?row - 1. 
close_window () . 

end. ( *5 . IMPLEMENTATION APPROACH*) 

topic 'Figure 5-1'. 

window (, white, red, yellow, 1, 16,29,4) 
and 

say (' The screen will go blank 
for a few seconds while 
the files are being loaded. 

Press #fyellow SPACE#d to continue.') 
and 

collect () 
and 

dos ( ' SAFE_REV.EXE' , restore) 
and 

close_window ( ) . 
end. (*figure 5-1*) 

topic 'Figure 6-1'. 

(♦This section needs to be redone. The figure has been divided into 6 
seperate parts to be displayed seperately, however, 1 & 2 = Phase 0 
3 & 4 = Phase I, 5 = Phase II, Phase III is not shown, and Delta Phase = 6. 
This coding blinks a screen in between graphics which will be very confusing 
and unpleasant to the user.*) 
dos ( ' PAYSAFE1.EXE' , restore) . 
dos ( ' PAYSAFE2 . EXE ' , restore ) . 
dos ( ' PAYSAFE3 . EXE ' , restore ) . 
dos ( ' PAYSAFE4 . EXE ' , restore ) . 
dos ( ' PAYSAFE5 . EXE ' , restore ) . 
dos ( ' PAYSAFE6 . EXE' , restore) . 
end. (*Figure 6-1*) 

topic 'Appendix B' . 

window ('Appendix B' , blue, white, white, ?column, ?row, 74, 18) . 
say ( ' #e GENERIC HAZARD REPORTS 
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During the safety review process by MSFC on numerous payloads 
(including Spacelab and partial payloads) , it has become apparent that 
there are several types of hazards that are applicable to most payload 
elements and use essentially the same hazard controls. These hazards 
and controls have been incorporated on payload hazard reports and have 
been designated as "generic." The generic hazard reports can be used 
by the PED in the development of safety data, if they are applicable. 

In performing the hazard analyses, the PED should identify all hazards 
and causes, develop controls, and perform the verification necessary 
for safety certification. If a particular generic hazard report is 
applicable, the PED is free to use the form; however, the submitted 
report should be tailored to specific needs. All other hazards must 
be identified on unique hazard reports. Both unique and generic 
hazard reports are to be submitted in the PED safety data package. 


To assiste the PED in the safety data development, seven generic 
flight hazard reports (designated G-l through G-7) and three generic 
ground hazard reports (designated KG-1 through KG-3) are provided in 
the appendix. These hazard reports have been interspersed with notes 
to the PED to provide information or clarification of data to support 
the report . 


The examples from the appendix are provided through Hypertext links in 
Section 6.0 SAFETY DATA REQUIREMENTS FOR NEW MISSIONS. 


Press #fyellow SPACE#d to continue. '). 

column = ? column - 1. 
row = ?row - l . 
close_window () . 
end. (‘Appendix B*) 

topic 'Appendix C' . 
column = ?column + 1. 
row = ?row + l . 

window ('Appendix C' , blue, white, white, ?column, ?row, 74, 16) . 
say ( ' #e UNIQUE HAZARD REPORTS 

During the performance of the payload element (including experiments) 
hazards analyses, it is highly probable that hazards that do not fall 
into the category covered by generic hazard reports will be identified. 
These hazards are generally peculiar to a particular instrument/ 
experiment, or the hazard contols very significantly from the other 
payload elements. These hazards are identified and documented as 
unique hazard reports and should be designated with a unique report 
number . 

A tabulation of several hazard titles has been developed and is 
.presented as an aid to the PED in developing the safety data. These 
titles are proveded in #mTable C-l#m for flight hazards and #mTable C-2#m 
for ground hazards . 
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To further assist the PED in understanding the type of backup 
information required for safety data, tow examples of unique flight 
hazard reports have been provided in a Phase III configuration. 

These hazard reports relate to pyrotechnic release devices and a 
high-presence gas system. The backup information is typical of the 
data required for hazard report closure. 

There is one unique flight hazard report that must be submitted for 
each item of payload equipment, if applicable. This report deals with 
the loss of the payload cooling medium (Freon, water, rack air, cabin 
air, etc.) and is titled "Loss of Cooling." This is not categorized 
as a generic hazard because of the wide range of control and 
verification options which make such an inclusion impratical. 


The category itself can be "critical" for some designs and 
"catastrophic" for others, depending upon the hazard potential. 
Controls can range from no special controls, if cooling loss can be 
verified not to be a hazard, to a redundant set of automatic power 
cutoff equiment for a design with catastrophic hazard potential. 


Press #fyellow SPACE#d to continue. ') . 

column = ?column - 1. 
row = ?row - l . 
close_window () . 
end . ( *Appendix C* ) 

topic 'Table C-l' . 

column = ? column + 1. 
row = ?row + 1 . 

window ('TABLE C-l' , blue, white, white, ?column, ?row, 72, 16) . 
say ( ' 


EXAMPLES OF UNIQUE FLIGHT HAZARD TITLES 

This section lists titles in both areas. 
Please select the most appropriate one . 

tmORBITER MIDDECK OR SPACELAB MODULE#m 
#mORBITER PAYLOAD BAY#m 


Press #fyellow SPACE#d to continue.'). 


topic 'ORBITER MIDDECK OR SPACELAB MODULE', 
say ( ' #e 

Exposure of Crew to Broken Glass or Frangible Materials 
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Release of Toxic or Noxious Gas into Habitable Atmosphere 
Containment of Flammable Fluids 
Frangmentation or Failure of Rotating Equipment 
Explosion/Rupture of Batteries 
Contamination Because of Battery Electrolyte Leakage 
Electrical Shock from Biomedical Instrumentation System 
Improperly Stowed Equipment 
Untethered Experiment Apparatus 
Hazardous Touch Temperatures 
Exposure of Crew to Pathogenic Micro-Organisms 
Containment of Stowed Energy; e.g., Springs 
Explosion/Rupture of Pressure Systems 
Contamination Because of Release of Mercury 
Failure of Vacuum Venting Results in Loss of Orbiter/Module Atmosphere 

Use of Toxic Materials 

Eye Injury As A Result of Exposure to Laser or Other High- Intensity 

Light (Nonionizing Radiation) 

Overtemperature/Fire Resulting from Runaway Furnaces or Heaters 

Loss of Cooling 

Impediment for Emergency Egress of the Crew From the Module 

Inability to Restow/Relatch Experiment Equipment during Emergency 

Evacuation 

Use of Radioactive Materials 

Containment of Toxic Experiment Samples 

Press #f yellow SPACE#d to continue. '). 

end. (*ORBITER MIDDECK OR SPACELAB MODULE*) 

topic 'ORBITER PAYLOAD BAY', 
say ( ' #e 

Battery - Explosive Rupture/Leakage 
Collision Caused by Unsecured Hardware (e.g., Covers) 
Explosion/ Implosion of Experiment Container 
Use of Radioactive Materials 

Explosion/Rupture of Pressure Systems (Including Heat Pipes) 
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Collision Because of Experiment Pointing System Failure 
Cryogen Storage Tank Overpressurization 
Collision Because of Experiment Restraint Latch Failure 
Collision Among Payload Elements During RMS Operations 
Fire/Damage Becasue of High-Energy Laser; also Crew Exposure 
Premature Deployment of Mast (or other Deployable Elements) 
Premature Actuation of Pyrotechnic or other Release Devices 
Inability to Restow Deployable Payloads 
Inability to Clear Payload Bay Doors 
Release of Mercury into the Payload Bay 
Loose Equipment Jams Payload Bay Door Closure Mechanism 

Eye Damage Because of Improper Positioning of Reflecting Lasers 
Contamination Resulting from Release of Corrosive Materials 
Contact or recontact with the Orbiter or Deployed Payload Equipment 


Press #fyellow SPACE#d to continue. ') . 
end. ( *ORBITER PAYLOAD BAY*) 

column = ?column - 1. 
row = ?row - 1 . 
close_window () . 
end. (* Table C-l*) 

topic 'Table C-2' . 

column = ?column + 1. 
row = ?row + 1. 

window ('TABLE C-2' , blue, white, white, ?column, ?row, 72 , 16) . 
say ( ' #e 

EXAMPLES OF UNIQUE GROUND HAZARD TITLES 

Use of Radioactive Materials 

Release of Toxic Gases during Ground Operations 

Use of Laser /High- Intensity Light that could Casue Eye Damage 

Oxygen Displacement in Confined Areas 

Containment and Handling of Cryogenic Fluids 

Use of Spark (Ignition) Sources in Equipment Adjacent to Orbiter or 

Propellant Systems 
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Explosion/Rupture of Batteries 
Containment of Mercury 

Handling/Operations using Biological Specimens 
Use of Flammable Fluids during Ground Operations 
Premature Actuation of Pyrotechnic Devices 
Exposure of Ground Crew to Rotating Devices 


Press #fyellow SPACE#d to continue. '). 
column = ?column - 1 . 
row = ?row - 1. 
close_window ( ) . 
end. (* Table C-2*) 

topic 'Section 4.0'. 

new_kb ( ' SEC4MR0FE . HKB ' ) . 
end. (*Section 4.0*) 

topic 'Appendix B of JA-447' . 
column = ?column + 1. 
row = ?row + 1. 

window ('Appendix B of JA-447' , blue, white, white, ?column, ?row, 73, 17) . 
say ( ' #e DATA REQUIREMENT DESCRIPTIONS 

PAYLOAD ELEMENT DEVELOPER (PED) PREPARED 

Contained in this appendix are descriptions and instructions for prep- 
aration of the data required from the Payload Element Developer (PED) . 
Following is the data requirements list for those documents to be 
prepared by the PED. Instructions for preparing the documents follow 
this list (however, they are not proveded in this software due to 
limited computer storage space) . 


NUMBER 

TITLE 

DEFINED 

( Page ) 

EX-R-01B 

EXPERIMENT REQUIREMENTS 
DOCUMENT (ERD) 

Instructions (Bl/0) 
(UAH software available) 

EX-D-01B 

PAYLOAD ELEMENT MASS 
PROPERTIES STATUS REPORT 

Instructions 

(B2/0) 

NUMBER 

TITLE 

DEFINED 

(Page) 

EX-D-02B 

ASSEMBLY AND INSTALLATION 
(A&I ) DRAWINGS 

Instructions 

(B3/0) 

EX-D-03B 

INTERFACE SCHEMATICS 

Instructions 

(B4/0) 

EX-D-04B 

MATERIALS USAGE LIST 

Instructions 

(B5/0) 

EX-D-05B 

MATERIALS USAGE AGREEMENT 

Instructions 

(B6/0) 

EX-V-01B 

INSTRUMENT/FACILITY/MPE/ 

Instructions 

(B7/0) 


ECE VERIFICATION PLAN 
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EX-V-02B 

VERIFICATION ANALYASIS 
REPORT 

Instructions 

(B8/0) 

NUMBER 

TITLE 

DEFINED 

(Page) 

EX-V-03B 

VERIFICATION TEST REPORT 

Instructions 

(B9/0) 

EX-S-01B 

SAFETY COMPLIANCE DATA 
PACKAGE 

Instructions (B10/0) 
(UAH software available) 

EX-S-02B 

SAFETY -CRITICAL STRUCTURES 
DATA PACKAGE 

Instructions 

(Bll/0) 

EX-D-06B 

POINTING CONTROL DYNAMICS 
DATA REQUIREMENTS DOCUMENT 

Instructions 

(B12/0) 

EX-F-01B ONBOARD FLIGHT PROCEDURES 

Press #fyellow SPACE#d 
column = ? column - 1. 
row = ?row - 1. 
close^window ( ) . 
end. (* Appendix B of JA-447*) 

Instructions 
to continue. ') 

(B13/0) 


topic 'Appendix F' . 

processlist = ['F.l BACKGROUND AND INTRODUCTION', 

' F . 2 ENGINEERING CHANGE REQUEST PREPARATION', 

' F . 3 CHANGE REQUEST PROCESSING', 

'QUIT'] . 

process = ' ' . 
column = ?column + 1. 
row = ?row + 1 . 

window ('Appendix F of JA-447' , blue, white, white, ?column, ?row, 72 , 16 ) . 
while Pprocess <> 'QUIT' 
then 

ask ( ' #e 

CHANGE REQUEST PREPARATION AND PROCESSING 

Please select the section you wish to continue with. ', process, 
Pprocesslist ) 
and 

if Pprocess = 'F.l BACKGROUND AND INTRODUCTION' 
then 

do ('F.l BACKGROUND AND INTRODUCTION') 

else 

if Pprocess = 'F.2 ENGINEERING CHANGE REQUEST PREPARATION' 
then 

do ('F.2 ENGINEERING CHANGE REQUEST PREPARATION') 

else 

if ?process = 'F.3 CHANGE REQUEST PROCESSING' 
then 

do ('F.3 CHANGE REQUEST PROCESSING'). 


topic 'F.l BACKGROUND AND INTRODUCTION', 
column = ? column + 1 . 
row = ?row + 1. 

window ('Background and Introduction' , blue, white, white, ?column, ?row, 70, 15) . 
say ( ' #e 
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During the development of a payload element, changes will occur to 
the hardware or its use that require coordination with the Payload 
Mission Manager (PMM) . Generally, these changes are those affecting 
payload interfaces with the carrier/mission-peculiar equipment (MPE) , 
flight and ground safety, and flight and ground operations. During 
the design phase, these changes are addressed in the appropriate 
documentation for each design review. However, after baselining of 
program documentation at the PMM Level II Configuration Control 
Board or one of the Level III Control Boards (Engineering and Flight 
Operations) , changes to the affected documentation will be considered 
only after submittal of an Engineering Change Request (ECR) form. 


It should be noted that changes to documentation that cause a change 
to the Level II Control documents should not be incorporated until 
the Level II change is approved. This formal control provides a basis 
for performing analyses or trades at the integrated payload level to 
ensure that provisions for the changes are feasible and compatible. 
The Spacelab Payload Accommodation Handbook (SPAH) , is considered a 
baselined Level II document even though it is not controlled by the 
PMM. Therefore, all PED nonstandard interfaces to the Spacelab, as 
defined by the SPAH, will also require an ECR. The words "This is 
a SPAH Deviation" should be placed at the bottom of block 16. 

Waivers or deviations, if any, which are against a requirements 
document other than SPAH should also use the ECR form. 


An ECR should discuss all affected documentation and include 
supporting rationale sufficient to allow a total evaluation of 
change impacts. For example, changes to the safety data package 
required by an ECR to the PED IIA should be addressed as part of 
the affected documentation. Also, operational changes (e.g., FOs) 
which result if the ECR is approved should be described in some 
detail . 


In summary, ECRs should: 

Identify all affected documentation and delineate changes required 

Define sufficient supporting rationale/inf ormation to allow a total 
evaluation of the proposed change' 's impact 

Include updated hazard reports with associated descriptive material 

Provide sufficient information to revise O&IAs (DILs, procedures, 
FOs, etc.) where not presently baselined 

Highlight where proposed change constitutes a deviation to the 
SPAH or other mission manager levied requirement 

Press #fyellow SPACE#d to continue.'), 
column = ? column - 1. 
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row = ?row - 1 . 
close_window () . 

end. (*F. 1 BACKGROUND AND INTRODUCTION*) 


topic ' F . 2 ENGINEERING CHANGE REQUEST 
column = ?column + 1 . 
row = ?row + 1. 

window ('Engineering Change Request 
?row, 70,15) . 
say ( ' #e 


PREPARATION' . 

Preparation' , blue, white, white, ?column, 


The Engineering Change Request (ECR) form #mFigure F-l#m is a standard 
MSFC form used for requesting and approving changes. The instruc- 
tions for completing the ECR form are found in #mFigure F-2#m. The PED 
shall use this form. The instructions for preparing the form are 
modified as follows: 


Space Number 
2 
5 

6 and 7 
10 
11 
12 

Space Number 
13 
16 

17 

20 

21 


Modification 

Omit 

PMM Name 
Omit 

Enter required approval date . 

Enter name of your project. 

Enter a list of your elements and any 
interfacing elements affected by the change . 

Modification 

Omit 

For nonstandard interfaces to Spacelab, add: 

"This is a SPAH deviation." 

Do not include costs. 

Not required by PMM: however, the PED may use 
Enter payload element developer authorized 
signature . 


The use of this form does not preclude technical or programmatic 
discussions; however, it is the basis for establishing a new 
baseline from which to proceed in either hardware or software 
development or mission integration. 


Press #fyellow SPACE#d to continue.') . 
column = ?column - 1. 
row = ?row - 1 . 
close_window () . 

end. ( *F . 2 ENGINEERING CHANGE REQUEST PREPARATION*) 


topic ' F . 3 CHANGE REQUEST PROCESSING', 
column = ? column + 1. 
row = ?row + 1 . 

window ('Change Request Processing' , blue, white,white, ?column, ?row, 70, 14) . 
say ( ' #e 

Upon receipt of the ECR, the PMM integration team will evaluate 
the change for possible impact on other payload elements and/or 
the allocation of available resources. Based on this evaluation, 
the change may be dispositioned immediately or identification of 
analyses, trades, and coordination with other PEDs will be done 
to allow disposition. If the "Need Date" cannot be met, the PMM 
will notify the PED to assist in developing a workaround. The 
disposition of the change request, if other than approved, will 
be coordinated with the PED, and the ECR will document the results 
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of that coordination. 


Press #fyellow SPACE#d to continue. ') . 
column = ?column - 1 . 
row = ?row - 1. 
close_window (). 

end. ( *F . 3 CHANGE REQUEST PROCESSING*) 

column = Pcolumn - 1. 
row = ?row - 1. 
close_window () . 
end. (*Appendix F of JA-447*) 

topic 'Figure F-l' . 
row = ? row + 1 . 

window ('Figure F-l ECR Form' , blue , white , white , 3 , ?row, 76 , 15) . 


say ( ' #e 
1. NUMBER: 

2. PCN : 


MSFC 

3. DATE: 

4. PAGE 



ENGINEERING 

CHANGE REQUEST 


1 OF 

5. TO: 


6. THUR: 


7. FROM: 


8. TITLE OF 

CHANGE 






9. RECOMMENDED PRIORITY 10. NEED DATE: 

Emergency Urgent Routine 


11. PROGRAM (S) /PROJECT (S) AFFECTED: 


12. END ITEM (S) AFFECTED BY NOMENCLATURE: 


13. RECOMMENDED EFFECTIVITY : 


14. BASELINE DOCUMENTATION AFFECTED (Specs, ICD, etc.): 


15. RELATED CHANGES (ECR, ECP, CR, etc . ) BY NUMBER: 


16. JUSTIFICATION FOR CHANGE (Include effect if not incorporated) : 


17. EFFECTS ON: 

Hardware Software Facility 

Schedule (See Enclosure for impact) 

Cost (Estimated cost included in Enclosure 


Requirements Document 
Other (Specify) 

') 


18. DESCRIPTION OF CHANGE (Include reference to enclosures): 


19. SIGNATURE OF ORIGINATOR: DATE: TELEPHONE NUMBER: OFFICE SYMBOL: 


20. CONCURRENCE 
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SIGNATURE & ORGANIZATION: 


DATE: 


SIGNATURE Sc ORGANIZATION: 


DATE: 


21. TECHNICAL APPROVAL 

SIGNATURE Sc ORGANIZATION: DATE: SIGNATURE Sc ORGANIZATION: DATE: 


Press #fyellow SPACE#d to continue. '). 

row = ?row - 1. 
close_window ( ) . 
end. (^Figure F-l*) 

topic 'Figure F-2'. 
row = ?row + 1 . 

window ('Figure F-2 ECR Form Instructions' , blue, white, white, 4, ?row, 74, 15) . 
say ( ' #e 


ENGINEERING CHANGE REQUEST 

GENERAL REQUIREMENTS - This ECR shall provide the information 
outlined in the ensuing item numbered entries in order that the 
request may be evaluated from the viewpoint of engineering, 
production, maintenance, cost, and supply by all effected parties. 

An entry must be made in each line or block. "Not Applicable" (NA) 
or like terms may be used only after due consideration. Enclosures 
should be used to provide comprehensive information (supplemented 
with necessary exhibits, sketches, and drawings) in sufficient detail 
to enable an understanding of the total impact of the change. The 
item numbers are keyed to the ECR form. 


1. NUMBER - The originating organization shall assign the ECR number 
based on the following numbering system: a 4 digit prefix consist- 
ing of the letters assigned to the organization in the MSFC 
organization chart, followed by a dash and a 4 digit alphanumeric 
number for the sequence of ECR issued by that organization. 

2. PCN - Enter the Program Control Number (PCN) assigned to this change. 

This may be a new number or the number of a package against which the 

ECR is written. The PCN shall be obtained from the applicable Program 
/Project Configuration Managment Office.. 

3. DATE - Enter date form is prepared. 

4. PAGE - Enter Page 1 of 1, 1 of 2, etc. as appropriate. 


5. TO - Enter the title and mailing symbol of the Program/ Projects 
. /End Item Office to which the ECR will be routed. 
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6 . THUR - Enter the title and mailing symbol of the organization 
focal point through which the ECR is to be routed. If not 
established enter "Not Applicable." 

7. FROM - Enter the title and mailing symbol of the organization 
initiating the ECR. 

8. TITLE - Enter a brief and concise title which reflects the intent of 
the ECR. 

9. RECOMMENDED PRIORITY - Check appropriate priority in accordance 
with the following definitions: 

#mEmergency#m #mUrgent#m #mRoutine#m 


10. NEED DATE - Enter date that change prepared by this ECR needs to 
be incorporated. 

11. PROGRAM (S) /PROJECT (S) AFFECTED - Enter the Unique Project Number (s) 
from the Agency Wide Coding Structure and enter title (s) of 
program (s) /project (s) affected (e.g., ASTP, HEAO, Shuttle, etc.). 

12. END ITEM (S) AFFECTED BY NOMENCLATURE - Enter nomenclature of all 
the end items affected by the change (e.g., S-IB Stage, 

Instrument Unit, Spacecraft, External Tank, etc.). 

13. RECOMMENDED EFFECTIVITY - Enter recommended effectivity; 
e.g., vehicle effectivity, end item effectivity (by serial 
number), launch facility effectivity, etc. 


14. BASELINE DOCUMENTATION AFFECTED - Enter number (s), including 
revision letter, of baseline documentation affected by this ECR; 
e.g., specif ication (s) , interface control document (s), etc. 

15. RELATED CHANGES - Enter the number (s) of any changes (ECPs, ECRs, 
CRs, etc.) related to this ECR. 

16 . JUSTIFICATION FOR CHANGE - Describe which requirements 
previously established will not be met and how this change will 
assure that provision, or on what the net cost reduction is based 
and how determined. The effect of not incorporating the change 
shall be described. 

17. EFFECTS ON - Self explanatory, check the approprate blocks. 

As appropriate, include an enclose providing breakdown of costs 
and/or schedule impact . 


18. DESCRIPTION OF CHANGE - Enter a clear statement explaining 

fully the technical problem which needs correcting or improving 
(i.e., "It is necessary to increase the capability of this unit 

in order to ....," or "The unit will not operate as planned 

until the following changes are made:..."). Include, as applicable, 
a description of the change impact on areas affected by each item 
checked in EFFECTS ON; e.g., safety, reliability, ground/flight 
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tapes, single point failures, weight, propulsion, critical 
components, mission operations, redlines, spares, test requirements, 
specifications, and criteria, etc. When the ECR affects safety, 
reliability, ordnance and/or critical components, the ECR shall 
include the applicable part of the FMEA and/or safety (hazards) 
analysis for the change . 


19. ORIGINATOR - Enter the signature, date, telephone number and 
organization symbol of the ECR originator. 

20. CONCURRENCE - Enter persons consulted or concurrences obtained. 
Person consulted: Indicate names of key persons consulted, within 
either the originating organization or other. Concurrences 
obtained: Obtain signature of any concurrences required by the 
originating organization. Any objections to proposed change should 
be so noted. 

21. TECHNICAL APPROVAL - Enter signature of persons which must 
technically approve the ECR prior to transmittal to the applicable 
Program/Project /End Item Office for CCB processing. 


Press #fyellow SPACE#d to continue. '). 


topic 'Emergency' . 

column = ? column + 1. 
row = ?row + 1. 

window ( ' Emergency' , blue, white, white, ?column, ?row, 71,13) . 
say ( ' #e 

An emergency priority shall be assigned to a proposed 
engineering change to correct a safety condition which could 
result in fatal or serious injury to personnel or extensive 
damage or destruction of equipment . Such conditins usually will 
require withdrawing the end item from service temporarily, or 
suspension of the end item operation, or discontinuence of 
further testing or development pending resolution of such conditions. 
In addition, stray electromagnetic radiation or radio frequency 
interference causing spurious command or control signals in 
equipment, require emergency action where safety conditions 
explained above are affected. 

Press #fyellow SPACE#d to continue . ' ) . 

column = ?column - 1 . 
row = ?row - 1. 
close_window ( ) . 
end . ( * erne rgency * ) 

topic 'Urgent' . 

column = ? column + 1. 
row = ?row + 1 . 

window ( 'Urgent ', blue, white, white, ?column, ?row, 71, 13) . 
say ( ' #e An urgent priortiy shall be assigned to a proposed 
engineering change to correct a potentially hazardous 
condition, the uncorrected existence of which could result 
in injury to personnel or damage to equipment and reduce 
the misssion effectiveness of the equipment. Such conditions 
compromise safety and embody risk within reasonable limits 
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wherein affected equipment is continued in use, after the 
operator has been informed of the hazard and appropriate 
precautions have been defined and distributed to the user. 

This classification may also be used for those changes 
necessary to meet contractual requirements when lead time 
would necessitate slipping approved production, activation, 
or construction schedules. 

The urgent classification may also be used by the procuring 
activity for mission capability changes, when in its opinion, 
the nonincorporation of the changes at the earliest possible 
time would compromise the mission capability to a degree that 
would be unacceptable for contract production or mission launch 
schedules. Changes associated with interface problems, resulting 
from compatibility changes made by the other contractors, shall 
be classified as urgent. 


Press #fyellow SPACE#d to continue. ') . 

column = ?column - 1. 
row = ?row - 1 . 
close_window () . 
end. (* urgent*) 

topic 'Routine' . 

column = ?column + 1. 
row = ?row + 1 . 

window ('Routine' , blue, white, white, ?column, ?row, 71, 13) . 
say ( ' #e 


A routine priority shall be assigned to a proposed 
engineering change when emergency or urgent is not applicable. 


Press #fyellow SPACE#d to continue. '). 
column = ?column - 1. 
row = ?row - 1 . 
close_window () . 
end. (*routine*) 

row = ?row - 1. 
close_window () . 
end. (*Figure F-2*) 

topic 'Section 5.0'. 
load ('NSTS5.HKB' ) . 
do ( ' Sect5 . 0 ' ) . 
close ('NSTS5.HKB' ) . 
end. (*Section 5.0 of NSTS 13830*) 

(♦created 6/30/92 - 7/1/92*) 

(♦last edited 2/22/94*) 
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(*SEC6SUB . KB This section covers all of the phases and allows the user to 
fill out the forms needed to make up the PED Safety Compliance Data Package 
including making changes to previous answers. *) 

curdir is read_line ('CURDIR.DAT'). 

curdir = string_replace (?curdir, ' ' , ' ' , 8) . 

eof = number_to_char (26) . 

column = 3 . 

row = 3 . 

haznum = 1 . 

yn = ['YES' , 'NO' ] . 

do (sec6) . 

topic ' SEC6 ' . 

window ('SAFETY COMPLIANCE DATA PACKAGE blue , white , white, ?column, ?row, 76 , 18 ) . 
column = ? column + 1. 
row = ? row + 1 . 

window ('6.0 SAFETY DATA REQUIREMENTS FOR NEW MISSION' , blue , white , white , 
?column, ?row, 74 , 17) . 

listsix = ['6.1 FLIGHT SAFETY COMPLIANCE DATA', 

'6.2 GROUND SAFETY COMPLIANCE DATA', 

'QUIT'] . 


sixstart = ' ' . 

while ?sixstart <> 'QUIT' 
then 

ask ( ' #e 


Please choose which section you wish to continue with. ', sixstart , ?listsix) 
and 

if ?sixstart = '6.1 FLIGHT SAFETY COMPLIANCE DATA' 
then 

do ( ' sixsubl ' ) 

else 

if ?sixstart = '6.2 GROUND SAFETY COMPLIANCE DATA' 
then 

do ( ' sixsub2 ' ) 

else 

if Tsixstart = 'QUIT' 
then 

new kb ( ' SAFJA012 . HKB ' ) . 


topic ' sixsubl ' . 

column = ?column + 1. 
row = ?row + 1 . 

window ('6.1 FLIGHT SAFETY COMPLIANCE DATA' , blue , white , white , ?column. 


subllist = [ 


,72,16) . 


['6.1.1 

Phase 

'6.1.2 

Phase 

'6.1.3 

Phase 

'6.1.4 

Phase 

'6.1.5 
'QUIT' ] . 

Delta 


subone = 


0 Flight Safety Review' , 


while ?subone <> 'QUIT' 


D*53 


then 
ask ( ' 

Please choose the section you wish to continue with.#n' , subone, ?subllist) 
and 

if ?subone = '6.1.1 Phase 0 Flight Safety Review' 
then 

do ('Phase 0 Flight Safety Review') 

else 

if ?subone = '6.1.2 Phase I Flight Safety Review' 
then 

do ('Phase I Flight Safety Review') 

else 

if ?subone = '6.1.3 Phase II Flight Safety Review' 
then 

do ('Phase II Flight Safety Review') 

else 

if ?subone = '6.1.4 Phase III Flight Safety Review' 
then 

do (' Phase III Flight Safety Review') 

else 

if ?subone = '6.1.5 Delta Phase III Flight Safety Review' 
then 

do ('Delta Phase III Flight Safety Review') 

else 

if ?subone = 'QUIT' 
then 

column = ? column - 1 
and 

row = ?row - 1 
and 

close_window() . 

topic 'Phase 0 Flight Safety Review', 
column = ?column + 1. 
row = ?row + 1 . 

window ('6.1.1 Phase 0 Flight Safety Review' , blue, white, white, ? column, 
?row, 71,15) . 
phaseOlist = [ 

'6. 1.1.1 PED Phase 0 Flight Safety Compliance Data Package', 

'6. 1.1. 2 PMM Activities' , 

'QUIT' ] . 
choiceO = ' ' . 
while ?choiceO <> 'QUIT' 
then 

ask ( ' #e 

Please choose which section you wish to continue with. ', choiceO , 
?phaseOlist ) 
and 

if ?choiceO = 

'6. 1.1.1 PED Phase 0 Flight Safety Compliance Data Package' 
then 

do ('PED Phase 0 Flight Safety Compliance Data Package') 

else 

if ?choiceO = '6. 1.1. 2 PMM Activities' 
then 

do ('PMM Activities') 

else 

if ? choiceO = 'QUIT' 
then 
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column = ? column - l 
and 

row = ?row - 1 
and 

close_window () . 

topic 'PED Phase 0 Flight Safety Compliance Data Package', 
column = ?column + 1. 
row = ?row + 1. 

window ('6. 1.1.1 PED Phase 0 Flight Safety Compliance Data Package', 
blue, white, white, ?column, ?row, 70,14) . 
say ( ' 

The objectives of the Phase 0 Report are to conceptually describe 
the payload element and its operation and to identify all potential 
hazards. This information is documented in the PED Phase 0 safety 
compliance data and is included in the data package for review at 
the PED PRR per Figure 6-1. 

Press #fyellow SPACE#d to continue.') 

and 

do (phaseOreport ) . 

topic 'phaseOreport' . 
ansO = ' ' . 
while ?ans0 <> 'NO' 
then 
ask ( ' 

The PED shall include the following information in the Phase 0 data 
package : 

Payload Element Overview, 

Safety Critical Subsystems Descriptions, 

Experiment Safety Package Cover Sheet (ESPCS) , 

Phase 0 Hazard Reports, 

STS Payload Safety Requirements Applicability Matrix. 

Would you like to begin filling out the documentation? ', ansO , ?yn) 
and 

if ?ans0 = 'YES' 
then 

new_kb ( ' PHOFLDOC . HKB ' ) . 
end. (*phaseOreport*) 

column = ?column - 1. 
row = ?row - 1 . 
close_window ( ) . 

end. ( *6. 1.1.1 PED Phase 0 Flight Safety Compliance Data Package*) 

topic ' PMM Activities', 
column = ? column + 1 . 
row = ?row + 1 . 

window ('6. 1.1. 2 PMM Activities' , blue, white, white, ?column, ?row, 70, 14) . 
say ( ' 

PED safety data are reviewed by the PMM for the PED PRR, and 
recommended/required revisions are presented to the PED via Review 
Item Discrepancies/Discrepancy Notices (RIDs/DNs) at the PED PRR. 

The PED will incorporate the agreed-upon revisions in the PED 
Phase 0 data in time to allow the revised report to be included in 
the I PL Safety Compliance Data Package (see Table 6-1) . The IPL 
Requirements Review (IPL RR) is typically held after the last PED 
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PRR or as required by the PMM to meet mission requirements. The 
Phase 0 flight safety review with the NSTS (JSC) will subsequently 
be conducted by the PMM based on updated IPL RR safety data. 

Press #fyellow SPACE#d to continue . ' ) . 
column = ? column - 1. 
row = ?row - 1. 
close_window ( ) . 

end. (*6.1.1. 2 PMM Activities*) 
end. (*Phase 0 Flight Safety Review*) 

topic 'Phase I Flight Safety Review', 
column = ? column + 1. 
row = ? row + 1 . 

window ('6.1.2 Phase I Flight Safety Review' , blue, white, white, 

?column, ?row, 71 , 15) . 
phasellist = [ 

'6. 1.2.1 PED Phase I Flight Safety Compliance Data Package', 
'6. 1.2. 2 PMM Activities', 

'QUIT'] . 
choicel = ' ' . 
while ?choiceI <> 'QUIT' 
then 

ask ( ' #e 

Please choose which section you wish to continue with. choicel, 
?phasellist) 
and 

if ?choiceI = 

'6. 1.2.1 PED Phase I Flight Safety Compliance Data Package' 
then 

do ('PED Phase I Flight Safety Compliance Data Package') 

else 

if ?choiceI = '6. 1.2. 2 PMM Activities' 
then 

do ( ' PMM Activities ' ) 

61.S6 

if ? choicel = 'QUIT' 
then 

column = ? column - 1 
and 

row = ?row - 1 
and 

close_window () . 

topic 'PED Phase I Flight Safety Compliance Data Package', 
column = ?column + 1. 
row = ?row + 1. 

window ('6. 1.2.1 PED Phase I Flight Safety Compliance Data Package', 
blue, white, white, ?column, ?row, 70,14) . 
say ( ' 

The objective of the Phase I data is to present a safety analysis 
that reflects the preliminary payload element design. These data 
are included in the data package for review at the PED Preliminary 
Design Review (PED PDR) , as shown in #mFigure 5-l#m and Figure 6-1. 

The content will mature from the conceptual phase to include the 
following information. 

Press #fyellow SPACE#d to continue . ' ) 
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and 

do (phaselreport ) . 

topic 'phaselreport'. 
ansi = ' ' . 
while ?ansl <> 'NO' 
then 

ask ( ' #e 

The PED shall include the following information in the Phase I data 
package: Payload Element Description and Mission Scenario 

Safety Critical Subsystems Descriptions 
Experiment Safety Package Cover Sheet (ESPCS) 

NSTS Payload Safety Requirements Applicability Matrix 
Phase I Hazard Reports 

Failure Mode and Effects Analysis (FMEA) 

Ionizing Radiation Source Data Sheets 

Would you like to begin filling out the documentation? ansi , ?yn) 
and 

if ?ansl = 'YES' 
then 

new_kb ( ' PHIFLDOC . HKB ' ) . 
end. (*phaselreport*) 
column = ? column - 1. 
row = ?row - l . 
close_window () . 

end. ( *6. 1.2.1 PED Phase I Flight Safety Compliance Data Package*) 

topic ' PMM Activities' . 
column = ?column + 1. 
row = ?row + 1 . 

window ('6. 1.2. 2 PMM Activities' ,blue, white, white, ?column, ?row, 70, 14) . 
say (' 

PED safety data are reviewed by the PMM for the PED PDR, and 
recommended/required revisions are presented to the PED via 
RIDs/DNs at the PED PDR. The PED will incorporate the agreed 
to revisions in the PED Phase I data in time to allow the 
PMM to include the revised report in the Phase I IPL Safety 
Compliance Data Package (see Table 6-1 Section ?) . These changes 
should reflect action item closures for actions received during 
the IPL Phase 0 Safety Review. The updated safety data will be 
submitted to the PMM, who will generate IPL hazard reports, 
develop hazard controls, establish verification methods and 
update the IPL safety data. 


System level tests and analyses for verification of IPL hazard 
controls will be developed and entered in the Integrated System 
Verification Plan as a part of activities already planned or as 
newly defined activities. The PMM will assemble the inputs from 
all PEDs into the IPL Phase I Flight Safety Compliance Data 
Package and provide it to the NSTS Flight Safety Review Panel for 
the Phase I review. Any additional requirements or actions items 
resulting from this review will be forwarded to the PED. 


Press #fyellow SPACE#d to continue.'), 
column = ?column - 1 . 
row = ?row - 1 . 
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close_window () . 

end. (*6.1.2. 2 PMM Activities*) 
end. (*Phase I Flight Safety Review*) 

topic 'Phase II Flight Safety Review', 
column = ? column + 1 . 
row = ?row + l . 

window ('6.1.3 Phase II Flight Safety Review' , blue, white, white, ?column, 
?row, 72,15) . 
phaselllist = [ 

'6. 1.3.1 PED Phase II Flight Safety Compliance Data Package', 
'6. 1.3. 2 PMM Activities', 

'QUIT' ] . 
choicell = ' ' . 
while ?choiceII <> 'QUIT' 
then 

ask ( ' #e 

Please choose which section you wish to continue with. ', choicell , 
?phaselllist ) 
and 

if Tchoicell = 

'6. 1.3.1 PED Phase II Flight Safety Compliance Data Package' 
then 

do ('PED Phase II Flight Safety Compliance Data Package') 

else 

if ?choiceII = '6. 1.3. 2 PMM Activities' 
then 

do ('PMM Activities') 

cXsb 

if ? choicell = 'QUIT' 
then 

column = ? column - 1 
and 

row = ?row - 1 
and 

close window ( ) . 


topic 'PED Phase II Flight Safety Compliance Data Package', 
column = ?column + 1. 
row = ?row + 1 . 

window ('6. 1.3.1 PED Phase II Flight Safety Compliance Data Package', 
blue , white, white, ? column, ?row, 71,14) . 
say ( [ ' 

The objective of the Phase II data is to present safety analyses 
that reflect the payload element#39s final design. These data include 
definitive, finalized hazard controls, and the planned specific 
verification methods to assure implementation and adequacy of hazard 
controls. These data are included with the data package for review at 
the PED Critical Design Review (PED CDR) as shown in #mFigure 5-l#m and 
Figure 6-1. The data will mature from the preliminary phase to 
include the following information. 


Press #fyellow SPACEtd to continue.']) 

and 

do (phase2 report) . 
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topic ' phase2report ' . 
ans2 = ' ' . 
while ?ans2 <> 'NO' 
then 

ask ('#e The PED shall include the following information in the Phase II data 
package: Payload Element Description, 

Safety Critical Subsystems Descriptions, 

Experiment Safety Package Cover Sheet (ESPCS) , 

Phase II Hazard Reports, Failures/Accidents, 

Safety Requirements Applicability Matrix, 

Failure Mode and Effects Analysis (FMEA) , 

Ionizing Radiation Source Data Sheets, 

Hazardous Radiation, Pyrotechnics. 

Would you like to begin filling out the documentation?#n#n' , ans2 , ?yn) 
and 

if ?ans2 = 'YES' 
then 

new_kb ( ' PHIIFDOC.HKB' ) . 
end. (*phase2report*) 
column = ? column - 1. 
row = ?row - 1 . 
close_window () . 

end. (*6 . 1 . 3 . 1 PED Phase II Flight Safety Compliance Data Package*) 

topic ' PMM Activities', 
column = ? column + 1. 
row = ?row + 1 . 

window ('6. 1.3. 2 PMM Activities' , blue, white, white, ?column, ?row, 70, 14) . 
say ( ' 

The PMM will review each PED Safety Compliance Data Package and 
concur in the proposed hazard controls and safety verification 
methods. This review will include any analysis, inspection, or 
test reports available that support the verification of hazard 
controls . Recommended revisions to the data submitted for the 
PED CDR will be identified by the PMM. The PED will incorporate 
the agreed-to revisions in the PED Phase II data in time to allow 
the revised report to be included in the Phase II IPL Safety 
Compliance Data Package (see Table 6-1) . The PMM will update and 
finalize all integrated payload hazard reports and will integrate 
the Payload Element safety data into the Integrated Payload Flight 
Safety Compliance Data Package which he will submit to IPL CDR for 
review and baselining. 

This package (incorporating the updates, actions, and closeouts 
mandated by the review) will be baselined as a result of the IPL 
CDR with the signature of each PED required on the baselining 
document. The baselined integrated payload safety compliance data 
package is then forwarded by the PMM to the NSTS Flight Safety 
Review Panel for the Phase II review. Action items or mandated 
changes identified during the Phase II review will be transmitted 
to the cognizant PED for incorporation and/or resolution. The PED 
shall ensure that required documentation changes resulting from 
these actions are incorporated into the baselined safety data 
package by the submission of the appropriate ECRs to the PMM 
Configuration Control Board. (See #mJA-447, MROFIE, Appendix F#m) . 

Press #fyellow SPACE#d to continue . ' ) . 
column = ? column - 1. 
row = ?row - 1. 
close window () . 
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end. (*6.1.3. 2 


PMM Activities*) 


topic ' JA-447 , MROFIE, Appendix F' . 
load ( ' AXFJA447 . HKB ' ) . 
do ( ' APPF' ) . 
close ( ' AXFJA447 . HKB ' ) . 
end. ( * JA-447 , MROFIE, Appendix F*) 


end. (*6.1.3 Phase II Flight Safety Review*) 


topic 'Phase III Flight Safety Review', 
column = ? column + 1. 
row = ?row + 1 . 

window ( ' 6 . 1 . 4 Phase III Flight Safety Review' , blue, white, white, 

?column, ?row, 71 , 15) . 
phasellllist = [ 

'6. 1.4.1 PED Phase III Flight Safety Compliance Data Package', 
'6. 1.4. 2 PMM Activities', 

'QUIT'] . 

choicelll = ' ' . 


while ’choicelll <> 'QUIT' 
then 

ask ( ' #e 

Please choose which section you wish to continue with choicelll , 
?phasellllist) 
and 

if ?choiceIII = 

'6. 1.4.1 PED Phase III Flight Safety Compliance Data Package' 
then 

do ('PED Phase III Flight Safety Compliance Data Package') 

else 

if ?choiceIII = '6. 1.4. 2 PMM Activities' 
then 

do ('PMM Activities') 

else 

if ?choiceIII = 'QUIT' 
then 

column = ? column - 1 
and 

row = ?row - 1 
and 

close window () . 


topic 'PED Phase III Flight Safety Compliance Data Package', 
column = ?column + 1 . 
row = ?row + 1 . 

window ('6. 1.4.1 PED Phase III Flight Safety Compliance Data' , blue, 
white, white , ? column, ?row, 70 , 15) . 
say (' 

The principal PED safety activity leading to the PED Integration 
Readiness Review (IRR) is the submittal of verification data to 
the PMM to substantiate the closeout of all open hazard reports or 
safety-related action items. 


PED Phase III flight safety compliance data consists of data from 
action and closeout items to ensure that the as-built equipment. 
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procedures and operations established as hazard controls have 
been fully verified to control the hazards and that all hazard 
control verifications have been satisfactorily completed. 
Modifications or changes to equipment or operations from the 
Phase II package will be documented and submitted as changes to 
the baselined safety data package . 

Assessment of changes will be performed to identify any impact 
to safety and hazard reports will be revised to reflect safety 
changes. Hazard report closure statements (i.e., status of 
verification block on JSC Form 542B) must contain the following 
elements : 

1) Statement (s) of fact concerning completion of applicable 
tests, analyses, or inspections. 

2) Completion date {month/year ) of applicable tests, analyses, 
or inspections. 

3) Summary statement or assessment including parametric data 
regarding results of the tests, analyses, or inspections (e.g., 
"Stress analysis results show positive margins of safety for 
all safety critical structures"). 

4) Identification of payload developer reports which contain 
test, analysis, or inspection results (i.e., title and number). 


These data are submitted before the PED IRR to the PMM for 
review and incorporation into the individual PED#39s section 
of the baselined Integrated Payload Flight Safety Compliance 
Data Package (see #mFigure 5-l#m and Figure 6-1) . A hazard report 
is not considered closed until all verification activities 
(analyses, tests, inspections) identified on the report have 
been satisfactorily completed and the results documented and 
approved by the PMM and the appropriate Safety Panels . 

Press #fyellow SPACE#d to continue.') 

and 

do (phase3 report) . 


topic ' phase3 report ' . 
ans3 = ' ' . 
while ?ans3 <> 'NO' 
then 

ask ( ' #e 

The PED shall include the following additional safety data 
submittals required specifically for review at the IRR: 

Open Safety Items List 
Pressure Vessel/System Log Book 
Failures/Accidents 

Certificate of Flight Safety Compliance 

Would you like to begin filling out the documentation?#n' , ans3 , ?yn) 
and 

if ?ans3 = 'YES' 
then 

new_kb ( ' PHI IIFDC . HKB ' ) . 
end. (*phase3 report*) 
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column = ?column - 1. 
row = ’row -1. 
close_window ( ) . 

end. (*6. 1.4.1. PED Phase III Flight Safety Compliance Data*) 

topic ' PMM Activities' . 
column = ? column + 1. 
row = ?row - 1 . 

window ('6. 1.4. 2 PMM Activities' , blue, white, white, ?column, ?row, 70, 14) 
say ( ' 

The PMM will review and assess the PED Phase III submittal and 
upgrade the Phase II data to a phase III status. He will 
initiate and maintain a Payload Flight Safety Verification 
Tracking Log documenting the status of -uncompleted (open) hazard 
control verifications at the time of the Phase III review and 
present these with his Certificate of NSTS Payload Safety 
Compliance to the Flight Safety Review Panel for its approval. 

This certificate provides certification from the PMM that the 
as-built Integrated Payload is safe and complies with all NSTS 
safety requirements . 

Press #fyellow SPACE#d to continue . ' ) . 
column = ?column - 1. 
row = ?row - 1. 
close_window ( ) . 

end. (*6.1.4. 2 PMM Activites*) 
end. (*6.1.4 Phase III Flight Safety Review*) 

topic 'Delta Phase III Flight Safety Review' . 
column = ? column + 1 . 
row = ?row + 1. 

window ('6.1.5 Delta Phase III Flight Safety Review' , blue, white, white, 
?column, ?row, 71 , 15) . 
delphaselist = [ 

'6. 1.5.1 PED Delta Phase III Flight Safety Compliance Data Package' 
'6. 1.5. 2 PMM Activities' , 

'QUIT' ] . 

choicedelta = ' ' . 

while ?choicedelta <> 'QUIT' 
then 

ask ( ' #e 

Please choose which section you wish to continue with. ', choicedelta, 
?delphaselist ) 
and 

if ?choicedelta = 

'6. 1.5.1 PED Delta Phase III Flight Safety Compliance Data Package' 
then 

do ('Delta Phase III Flight Safety Compliance Data Package') 

else 

if ?choicedelta = '6. 1.5. 2 PMM Activities' 
then 

do ('PMM Activities') 

else 

if ?choicedelta = 'QUIT' 
then 

column = ? column - 1 
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and 

row = ?row - 1 
and 

close_window () . 

topic 'Delta Phase III Flight Safety Compliance Data Package' . 
column = ?column + 1 . 
row = ?row + 1. 

window ('6. 1.5.1 PED Delta Phase III Flight Safety Compliance Data', 
blue, white, white, ?column, ?row, 70,14) . 
say (' 

The delta Phase III Safety Review will be conducted for all 
payloads at Launch - 2 mo. No change in PED hardware/software 
/operations is permitted following the original Phase III 
review unless the intended change is formally approved by the 
PMM before its incorporation. See section 5.0 of this document 
for definition of the requirements placed upon required/desired 
hardware/software/operations changes during this phase. 

Press #fyellow SPACE#d to continue . ' ) . 
column = ? column - 1. 
row = ?row - 1. 
close_window () . 

end. (*6. 1.5.1 PED Delta Phase III Flight Safety Compliance Data*) 

topic 'PMM Activities', 
column = ?column + 1 . 
row = ?row + 1 . 

window ('6. 1.5. 2 PMM Activities' , blue, white, white, ?column, ?row, 70, 14) . 
say ( ' 

The PMM will determine the impact to Integrated Payload Safety 
Compliance for all hardware/software/operations changes which 
occur subsequent to the Phase III safety review. He will provide 
an assessment to the NSTS Safety Review Panel that these changes 
have not invalidated the flight safety compliance. The closed-out 
Flight Safety Verification Tracking Log will be submitted at this 
review. 


Press #fyellow SPACE#d to continue.'), 
column = ?column - 1. 
row = ?row - 1. 
close_window () . 

end. (*6.1.5. 2 PMM Activities*) 
end. (*6.1.5 Delta Phase III Flight Safety Review*) 
end. (*sixsubl*) 


topic ' sixsub2 ' . 

column = ?column + 1. 


row = ?row + 1 . 


window ('6.2 
?row, 72,16) . 
sub2list = ['6.2.1 


GROUND SAFETY COMPLIANCE DATA' , blue , white, white , ?column. 


6 , 

6 

6 


2.2 

2.3 

2.4 


'QUIT' ] 


Phase 0 Ground Safety Review' , 
Phase I Ground Safety Review' , 
Phase II Ground Safety Review' , 
Phase III Ground Safety Review' , 


subtwo = ' ' . 

while ? subtwo <> 'QUIT' 
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then 
ask ( ' 

Ground safety data is developed to enable assessment of ground 
equipment and operations during payload integration and prelaunch 
activities and postflight operations. The data must consider 
ground support and checkout equipment, flight equipment operations, 
and hazardous processing including ground handling and equipment 
installation. The following are included in this data : ' , subtwo , ?sub2list ) 
and 

if ?subtwo = '6.2.1 Phase 0 Ground Safety Review' 
then 

do ('6.2.1 Phase 0 Ground Safety Review') 

else 

if ?subtwo = '6.2.2 Phase I Ground Safety Review' 
then 

do ('6.2.2 Phase I Ground Safety Review') 

else 

if ?subtwo = '6.2.3 Phase II Ground Safety Review' 
then 

do ('6.2.3 Phase II Ground Safety Review') 

else 

if ?subtwo = '6.2.4 Phase III Ground Safety Review' 
then 

do ('6.2.4 Phase III Ground Safety Review') 

else 

if ? subtwo = 'QUIT' 
then 

column = ? column - 1 
and 

row = ?row - 1 
and 

close_window() . 

topic '6.2.1 Phase 0 Ground Safety Review', 
column = ? column + 1 . 
row = ?row + 1. 

window ('6.2.1 Phase 0 Ground Safety Review' , blue, white, white, ? column, 
?row, 71,15) . 
gphasellist = [ 

'6. 2. 1.1 PED Phase 0 Ground Safety Compliance Data Package', 

'6. 2. 1.2 PMM Activities', 

'QUIT' ] . 

gchoicel = ' ' . 

while Pgchoicel <> 'QUIT' 
then 

ask ( ' #e 

Please choose which section you wish to continue with. ', gchoicel, 
?gphasellist) 
and 

if Pgchoicel = 

'6. 2. 1.1 PED Phase 0 Ground Safety Compliance Data Package' 

then 

do ('PED Phase 0 Ground Safety Compliance Data Package') 

else 

if Pgchoicel = '6. 2. 1.2 PMM Activities' 
then 

do ('PMM Activities') 
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else 

if ?gchoiceI = 'QUIT' 
then 

column = ?column - 1 
and 

row = ?row - 1 
and 

close_window (). 

topic ' PED Phase 0 Ground Safety Compliance Data Package', 
column = ?column + 1. 
row = ?row + 1. 

window ('6. 2. 1.1 PED Phase 0 Ground Safety Compliance Data Package', 

blue, white, white, ?column, ?row, 70,14) . 
say ( ' 

The objectives of the Phase 0 Ground Safety Data are to 
conceptually describe payload element subsystems and GSE and to 
identify potential hazards including hazards associated with 
operating flight equipment during ground operations. To accomplish 
these objectives, the PED shall include the following information 
in his Phase 0 ground safety data package at the PED Preliminary 
Requirements Review (PED PRR) as indicated in #mFigure 5-l#m and 
Figure 6-1. 


Press #fyellow SPACE#d to continue.') 

and 

do (phaseOpack) . 

topic 'phaseOpack' . 
ansgO = ' ' . 
while PansgO <> 'NO' 
then 
ask ( ' 

The PED shall include the following information in the Phase 0 data 
package : 

Payload Element Overview, 

Safety Critical Subsystems Descriptions, 

GSE Description, 

Phase 0 Ground Hazard Reports, 

Ground Operations Flow, 

Would you like to begin filling out the documentation? ', ansgO , ?yn) 
and 

if ? ansgO = 'YES' 
then 

new_kb ( ' PHOGDOC . HKB ' ) . 
end . ( *phase Opack* ) 

column = ? column - 1. 
row = ?row - 1. 
close_window () . 

end. ( *6. 2. 1.1 PED Phase 0 Ground Safety Compliance Data Package*) 

topic 'PMM Activities', 
column = ? column + 1. 
row = ?row + 1 . 

window ('6. 2. 1.2 PMM Activities' , blue, white, white, ?column, ?row, 70,14) 
say ( ' 
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The PMM activities for the Phase 0 Ground Safety Review are 
essentially the same as those for the Phase 0 Flight Safety 
Review. 


Press #fyellow SPACE#d to continue.'), 
column = ?column - l . 
row = ?row - 1. 
close_window () . 

end. (*6.2.1. 2 PMM Activities*) 
end. (*6.2.1 Phase 0 Ground Safety Review*) 

topic '6.2.2 Phase I Ground Safety Review', 
column = ?column + 1. 
row = ?row + 1 . 

window ( ' 6 . 2 . 2 Phase I Ground Safety Review' , blue, white, white, ?column, 
?row, 71, 15) . 
gphaselllist = [ 

'6. 2. 2.1 PED Phase I Ground Safety Compliance Data Package', 

'6. 2. 2. 2 PMM Activities', 

'QUIT'] . 

gchoicell = ' ' . 

while ?gchoiceII <> 'QUIT' 
then 

ask ( ' #e 

Please choose which section you wish to continue with .', gchoicell, 
?gphaselllist) 
and 

if Tgchoicell = 

'6. 2. 2.1 PED Phase I Ground Safety Compliance Data Package' 

then 

do ('PED Phase I Ground Safety Compliance Data Package') 

else 

if ?gchoiceII = '6. 2. 2. 2 PMM Activities' 
then 

do ('PMM Activities') 

else 

if ?gchoiceII = 'QUIT' 
then 

column = ? column - 1 
and 

row = ?row - 1 
and 

close_window () . 

topic 'PED Phase I Ground Safety Compliance Data Package', 
column = ? column + 1 . 
row a ?row + 1. 

window ('6. 2. 2.1 PED Phase I Ground Safety Compliance Data Package', 
blue, white, white, ?column, ?row, 70,14) . 
say (' 

The objective of the Phase I Ground Safety data is to present a 
preliminary analysis of potentially hazardous GSE and ground 
operations involving both flight and ground equipment. These 
data are included in the data package for review at the PED PDR 
(see #mFigure 5-l#m and Figure 6-1) . These ground safety data shall 
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contain the following list of information.' 


Press #fyellow SPACE#d to continue . ' ) 

and 

do (phaselllpack) . 

topic 'phaselllpack' . 
ansgl = ' ' . 
while ?ansgl <> 'NO' 
then 
ask ( ' 

The PED shall include the following information in the Phase I data 
package: Safety Critical Subsystem Description, 

Payload Element Description, GSE Description, 

List of Deliverable Items, Ground Flow Chart, 

Phase I Ground Hazard Reports, Ordnance Data, 

Ground Operations Scenario, Hazardous Radiation, 

Ionizing Source Data, Non- Ionizing Radiation. 

Would you like to begin filling out the documentation? ', ansgl , ?yn) 
and 

if ? ansgl = 'YES' 
then 

new_kb ( ' PHIGDOC . HKB ' ) . 
end. (*phaselllpack*) 
column = ? column - 1. 
row = ?row - 1. 
close_window ( ) . 

end. (*6 . 2 . 2 . 1 PED Phase I Ground Safety Compliance Data Package*) 

topic ' PMM Activities', 
column = ?column + 1. 
row = ?row + 1 . 

window ('6. 2. 2. 2 PMM Activities ', blue , white, white, ?column, ?row, 70 , 14 ) . 
say ( ' 

Activities related to the review of PED Phase I ground safety 
data and preparation of the IPL Phase I Report are similar to 
PMM flight safety activities for Phase I flight safety review. 


Press #fyellow SPACE#d to continue.'), 
column = ?column - 1. 
row = ?row - 1. 
close_window () . 

end. (*6.2.2. 2 PMM Activities*) 

end. (*6.2.2 Phase I Ground Safety Review*) 

topic '6.2.3 Phase II Ground Safety Review', 
column = ?column + 1 . 
row = ?row + 1. 

window ('6.2.3 Phase II Ground Safety Review' , blue, white, white, ?column, 
?row, 71,15) . 
gphasellllist = [ 

'6. 2. 3.1 PED Phase II Ground Safety Compliance Data Package', 
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'6. 2. 3. 2 PMM Activities', 

'QUIT' ] . 

gchoicelll = ' ' . 

while ?gchoiceIII <> 'QUIT' 
then 

ask ( ' #e 

Please choose which section you wish to continue with gchoicelll , 
?gphasellllist ) 
and 

if ?gchoiceIII = 

'6. 2. 3.1 PED Phase II Ground Safety Compliance Data Package' 
then 

do ('PED Phase II Ground Safety Compliance Data Package') 

else 

if ?gchoiceIII = '6. 2. 3. 2 PMM Activities' 
then 

do ('PMM Activities') 

else 

if ?gchoiceIII = 'QUIT' 
then 

column = ? column - 1 
and 

row = ?row - 1 
and 

close_window () . 

topic 'PED Phase II Ground Safety Compliance Data Package', 
column = ?column + 1. 
row = ?row + 1. 

window ( ' 6 . 2 . 3 . 1 PED Phase II Ground Safety Compliance Data Package', 
blue, white, white, ?column, ?row, 70, 14) . 
say ( ' 

The objective of the Phase II Ground Safety data is to present 
a safety analysis that reflects the GSE#39s final design and 
planned operations . These data are delivered with the data 
package for review at the PED CDR (#mFigure 5-l#m and Figure 6-1) . 

This ground safety data shall contain the following list. 


Press #fyellow SPACE#d to continue.') 

and 

do (phasellpack) . 

topic 'phasellpack' . 
ansgll = ' ' . 
while ?ansgll <> 'NO' 
then 

ask { ' The PED shall include the following information in the Pha 
data package: Safety-Critical Subsystem Description, 

Payload Element Description, 

GSE Descriptions, List of Deliverable Items, 

Operating Procedures, Hazardous Radiation, 

Phase II Ground Hazard Reports, 

Failures/Accidents Reports, Ordnance Data, 
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Ionizing Source Data, Non-Ionizing Radiation, 

Ground Operations Scenario. 

Would you like to begin filling out the documentation?#n' , ansgll , ?yn) 
and 

if ? ansgll = 'YES' 
then 

new_kb ( ' PHI IGDOC . HKB ' ) . 
end. (*phasellpack*) 
column = ?column - 1. 
row = ?row - 1 . 
close_window () . 

end. ( *6. 2. 3.1 PED Phase II Ground Safety Compliance Data Package*) 

topic ' PMM Activities', 
column = ?column + 1. 
row = ?row + 1 . 

window ( ' 6 . 2 . 3 . 2 PMM Activities' , blue , white , white, ?column, ?row, 70,14) . 
say ( ' 

Activities of the PMM related to review, integration and 
baselining of the PED Phase II ground safety data are similar 
to the flight safety activities of the PMM for the Phase II 
flight safety review. 


Press #fyellow SPACE#d to continue.') . 
column = ? column - 1. 
row = ?row - 1 . 
close_window () . 

end. (*6.2.3. 2 PMM Activities*) 
end. (*6.2.3 Phase II Ground Safety Review*) 

topic '6.2.4 Phase III Ground Safety Review', 
column = ?column + 1 . 
row = ?row + 1. 

window ('6.2.4 Phase III Ground Safety Review' , blue, white, white, 
?column, ?row, 71 , 15) . 
gphaselllllist = [ 

'6. 2. 4.1 PED Phase III Ground Safety Compliance Data Package', 

'6. 2. 4. 2 PMM Activities', 

'QUIT' ] . 

gchoicellll = ' ' . 

while ?gchoiceIIII <> 'QUIT' 
then 

ask ( ' #e 

Please choose which section you wish to continue with. ', gchoicellll , 
?gphaseIIIIlist) 
and 

if ?gchoiceIIII = 

'6. 2. 4.1 PED Phase III Ground Safety Compliance Data Package' 
then 

do ('PED Phase III Ground Safety Compliance Data Package') 

else 
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PMM Activities' 


if ?gchoiceIIII = '6. 2. 4. 2 
then 

do ('PMM Activities') 

else 

if ?gchoiceIIII = 'QUIT' 
then 

column = ?column - 1 
and 

row = ?row - 1 
and 

close window () . 


topic ' PED Phase III Ground Safety Compliance Data Package', 
column = ? column + 1. 
row = ?row + 1 . 

window ('6. 2. 4.1 PED Phase III Ground Safety Compliance Data', blue, 
white,white, ?column, ?row, 70, 14) . 
say ( [ ' 

The principal PED safety activity leading to the PED IRR and is 
the submittal of verification data to the PMM to substantiate the 
closeout of all open hazard reports or safety-related action 
items . 

PED Phase III ground safety compliance data consists of data from 
action and closeout items to ensure that the as-built equipment, 
procedures and operations established as hazard controls have 
been fully verified to control the hazards and that all hazard 
control verifications have been satisfactorily completed. 

Hardware /operations descriptions are updated to reflect 
modifications/changes which could impact safety. A finalized list 
of technical operating procedures with the hazardous procedures 
clearly identified is submitted. Copies of all procedures used 
to control ground hazards are to be submitted with the PED data 
package. Payload hazard reports are updated and supplemental data 
provided. Hazard report closure statements (i.e., status of 
verification block on JSC Form 542B) must contain the following 
elements : 

Statement (s) of fact concerning completion of applicable tests, 
analyses, or inspections. 

Completion date (month/year) of applicable tests, analyses, or 
inspections . 


Summary statement or assessment including parametric data 
regarding results of the tests, analyses, or inspections (e.g., 
"Stress analysis results show positive margins of safety for all 
safety critical structures"). 

Identification of payload developer reports which contain test, 
analysis, or inspection results (i.e., title and number). 

This data is submitted to the PMM by the PED via ECR before the 
PED IRR for review and incorporation into the individual PED#3 9s 
section of the baselined Integrated Payload Ground Safety 
Compliance Data Package. (See #mFigure 5-l#m and 6-1.) 

Press #fyellow SPACE#d to continue.']) 
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and 

do (phaselllpack) . 

topic 'phaselllpack' . 
ansglll = " . 
while ?ansgIII <> 'NO' 
then 
ask ( ' 

The PED shall include the following information in the Phase III 
data package: 

Open Safety Items List, 

Pressure Vessel/System Log Book, 

Failures/Accidents , 

Handling Equipment Certification, 

Certification of Ground Safety Compliance. 

Would you like to begin filling out the documentation?#n' , ansglll, ?yn) 
and 

if ?ansgIII = 'YES' 
then 

new_kb ( ' PHI I IGDC . HKB ' ) . 
end. (*phaselllpack*) 
column = ?column - 1. 
row = ? row - 1 . 
close_window () . 

end. (*6.2.4.1 PED Phase III Ground Safety Compliance Data*) 

topic 'PMM Activities' . 
column = ?column + 1. 
row = ?row + 1 . 

window ('6. 2. 4. 2 PMM Activities' ,blue, white, white, ?column, ?row, 70, 15) . 
say ( ' The PMM will update the IPL Ground Safety Data Package includin 
updates to the individual PED sections utilizing latest reviewed 
and accepted PED safety data inputs and forward it to the NSTS 
Ground Safety Review Panel for the Phase III review. He will also 
review, approve, and forward hazardous operating procedures 
prepared by the PED. The PMM will provide a Certificate of Safety 
Compliance to certify that the payload and the GSE fully comply 
with requirements of NHB 1700.7 and KHB 1700.7. The Phase III 
review must be accomplished before commencement of integration 
activities. Upon successful completion of the Phase III review, 
ground processing will be authorized by the NSTS Ground Safety 
Panel. The certification statement will be forwarded to the PMM 
and launch site integration authority. 

Press #fyellow SPACE#d to continue.'), 
column = ?column - 1 . 
row = ?row - 1 . 
close_window () . 

end. (*6.2.4. 2 PMM Activities*) 
end. (*6.2.4 Phase III Ground Safety Review*) 
end. (*sixsub2*) 

topic 'Figure 5-1' . 
collect 0 . 

dos (' SAFE_REV_.EXE' , restore) . 
end. (*Figure 5-1*) 

(★created 12/14/93*) 
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( *APPDB . KB This is a subprogram to display the hazard reports found 
in appendix b of JA-012. *) 

column = 3 . 
row = 3 . 

do ( ' Appendix B ' ) . 
topic 'Appendix B' . 

window ('SAFETY COMPLIANCE DATA PACKAGE' , blue , white , white , ?column, ?row, 76 , 
18) . 

report_opt ion is ['GENERIC FLIGHT HAZARDS', 

'GENERIC GROUND HAZARDS', 

' QUIT ' 3 . 

report_choice = ' ' . 
column = ?column + 1 . 
row = ?row + 1 . 

window ('Appendix B' , blue, white, white, ?column, ?row, 74 , 17) . 
say ( ' 

Appendix B: GENERIC HAZARD REPORTS 

During the safety review process by MSFC on numerous payloads 
(including Spacelab and partial payloads) , it has become apparent 
that there are several types of hazards that are applicable to 
most payload elements and use essentially the same hazard controls . 

These hazards and controls have been incorporated on payload 
hazard reports and have been designated as "generic." The generic 
hazard reports can be used by the PED in the development of safety 
data, if they are applicable. 

In performing the hazard analyses, the PED should identify all 
hazards and causes, develop controls, and perform the verification 
necessary for safety certification. If a particular generic hazard 
report is applicable, the PED is free to use the form; however, the 
submitted report should be tailored to specific needs. All other 
hazards must be identified on unique hazard reports . Both unique 
and generic hazard reports are to be submitted in the PED safety 
data package . 


To assiste the PED in the safety data development, seven generic 
flight hazard reports (designated G-l through G-7) and three 
generic ground hazard reports (designated KG-1 through KG-3) are 
provided in the appendix. These hazard reports have been inter- 
spersed with notes to the PED to provide information or clarifi- 
cation of data to support the report. 

Press #fyellow SPACE#d to continue. ') . 

while ?report_choice <> 'QUIT' 
then 

ask ( ' #e 

Which Hazard Reports do you wish to view?', report_choice , 
?report_option) 
and 

if ?report_choice = 'GENERIC FLIGHT HAZARDS' 
then 

do (fligthaz) 

else 

if ?report_choice = 'GENERIC GROUND HAZARDS' 
then 


D-72 


do ( groundha z ) 


else 

if ?report_choice = 'QUIT' 
then 

new_kb ( ' PHOFLDOC . HKB ' ) . 

topic 'fligthaz'. 

subloption = ['ELECTRICAL', 

' HUMAN FACTORS ' , 

' MATERIALS ' , 

' STRUCTURES ' , 

'QUIT' ] . 

sublchoice = ' ' . 
column = ?column + 1. 
row = ?row + 1 . 

window ('GENERIC FLIGHT HAZARDS ', blue , white , white , ?column, ?row, 73 , 16 ) . 
while ?sublchoice <> 'QUIT' 
then 

ask ( ' #e 

Which Flight Hazard Report Subsystem do you wish to view?', sublchoice, 
? subloption) 
and 

if ? sublchoice = 'ELECTRICAL' 
then 

do ('ELECTRICAL') 

else 

if ? sublchoice = 'HUMAN FACTORS' 
then 

do ( ' HUMAN FACTORS ' ) 

else 

if ? sublchoice = 'MATERIALS' 
then 

do ( ' MATERIALS ' ) 

else 

if ? sublchoice = 'STRUCTURES' 
then 

do ( ' STRUCTURES ' ) 

else 

if ?sublchoice = 'QUIT' 
then 

column = ?column - 1 
and 

row = ?row - 1 
and 

close_window ( ) . 

topic 'ELECTRICAL' . 

typeElist = [' INJURY/ ILLNESS ' , 

'FIRE' , 

'RADIATION' , 

'QUIT'] . 

typeans = ' ' . 
column = ?column + 1. 
row = ?row + 1 . 

window (' ELECTRICAL' , blue, white , white , ?column, ?row, 74 , 16) . 
while ? typeans <> 'QUIT' 
then 
ask ( ' 

Which Hazard Group would you like to view?' , typeans, PtypeElist) 
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and 

if ?typeans = ' INJURY/ ILLNESS ' 
then 

do ( ' INJURY/ ILLNESS' ) 

else 

if ?typeans = 'FIRE' 
then 

do ('FIRE' ) 

else 

if ?typeans = 'RADIATION' 
then 

do ('RADIATION') 

else 

if ?typeans = 'QUIT' 
then 

column = ?column - l 
and 

row = ?row - l 
and 

close window () . 


topic ' INJURY/ ILLNESS ' . 
column = ?column + 1. 


row = ?row + 1. 


window (' INJURY/ ILLNESS' , blue, white, white , ?column ( ?row, 74 , 15) . 


say ( ' 

PAYLOAD : 

SUBSYSTEM: Electrical 
HAZARD GROUP: Injury/Illness 
TITLE: Electrical Shock 


PAYLOAD HAZARD REPORT 

PHASE 


DATE 9-10-86 


| NO. G 


APPLICABLE SAFETY REQUIREMENTS: 
NHB 1700. 7A, paragraph 206, 213 


HAZARD CATEGORY 


X 


Catastrophic 

Critical 


DESCRIPTION OF HAZARD: 

Electrical shock to the flight crew could result from contact with 
voltages in excess of 30V. 

HAZARD CAUSES: 

1. Defective components, wires, or insulation coupled with 
inadequate bonding/grounding results in shock potential. 

2. Exposed terminals or high voltage sources accessible to the 
crew during opertions. 

HAZARD CONTROLS: 

1. Bonding and grounding will be (have been) accomplished in 
accordance with MIL-B-5087B. 

2. Bleed down circuitry will be (has been) provided for HV 
capacitors. High voltage sources will be (are) inaccessible to 
the crew and interlocks will be (have been) provided to remove 
power when operations require access to areas of exposure . 


NOTES TO PED: 
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1. Provide schematics of HV sources and interlocks, and identify 
voltage potential. If there is more than one area which would 
allow access to high voltage (e.g., exposed terminals or opening 
doors which could expose HV sources) , attach a table which denotes 
voltage, areas of exposure (equipment) , interlocks or controls, 
and switches for power removal . 

2. Electric shock may be catastrophic. Each potential source must 
be evaluated for hazard classification and adequacy of controls. 

SAFETY VERIFICATION METHODS: 

1. Test of bonding/grounding per MIL-B-5087B - Class R for 
energized equipment and Class S for others . 

2. Design review of equipment, inspection of as -built equipment, 
and test of interlocks . 

STATUS OF VERIFICATION: 

Phase I - (Provide a tentative schedule for completion of each 
inspection or test.) 

Phase II - (Specify schedule for the completion of each verification 
test, analysis, or inspection.) 

Phase III - (All safety verification should be complete. Briefly 
summaize the results of the completed tests, analyses, 
and/or inspections and provide verification completion dates. 

Refer to particular test/analysis reports and verification 
completion dates by document number and title. All open 
verifications shall be identified.) 


APPROVAL 
PHASE I 
PHASE II 
PHASE III 


PAYLOAD ORGANIZATION 


STS 


Press ifyellow SPACE#d to continue. '). 
column = ? column - 1 . 
row = ?row - 1 . 
close_window ( ) . 
end. (*injury/illness* ) 


topic 'FIRE' . 

column = ? column + 1. 
row = ?row + 1. 

window ('FIRE' , blue, white, white, ?column, ?row, 74, 15) . 
say (' PAYLOAD HAZARD REPORT 


PAYLOAD : 

SUBSYSTEM: Electrical 
HAZARD GROUP: Fire 
TITLE: Ignition Sources 


PHASE 

DATE 9-10-86 


APPLICABLE SAFETY REQUIREMENTS: 

NHB 1700. 7A, paragraph 206, 209.3, 213, 219 


HAZARD CATEGORY 
Catastrophic 
Critical 


| NO. G 


DESCRIPTION OF HAZARD: 

1. Overheating of electrical wiring results in ignition of flammable 
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materials . 

2 . Ignition of f lammable atmospheres in the payload bay during 
Orbiter entry/landing and postlanding operations. 


HAZARD CAUSES: 

1. Wiring/fusing size improper to protect downstream wiring from 
overheating in the event of a short or partial short circuit . 


2 . Normal equipment operation provides a spark or other ignition 
source for flammable gases in the payload bay. 


HAZARD CONTROLS: 

1. Wiring/fusing (including the instrument) will be (has been) 
selected to protect down- stream wiring in accordance with 
MIL-HDBK-978A (NASA), Volume II, Section 18 (Except 18.3 
and 18.4) . [For Spacelab payloads the wiring/cabling will 
be (has been) designed in accordance with SLP 2104 para 7.4 
to the first circuit protection device within the instrument 
and the instrument protected internally in accordance with 
NHB 5300.4 (3G) and MIL-HDBK-978A (NASA), Volume II, Section 
18 (Except 18.3 and 18.4).] 

NOTE TO PED: 

Polyvinylchloride insulation should not be used. 

2. Payload bay equipment will be de-energized during deorbit/ 
landing operations or potential ignition sources . (e .g. , switches, 
relays, motors) will be (have been) hermetically sealed. 

NOTES TO PED: 

1. Attach a simplified electrical schematic showing the protective 
device rating (Amps) and wire size (AWG) . 

2. Hazard ##2 is only applicable to, and should only be included 

for elements in the payload bay - the PED should specify the 
applicable portion of hazard control ##2, (i.e., no power applied 

or hermetic sealing) . 

3. Potential ignition sources from high temperature devices (e.g., 
furnaces, heaters, etc.) should be documented on unique Paylod 
Hazard Reports . ) 

SAFETY VERIFICATION METHODS: 

1. (a) Circuit analysis to verify wiring per MIL-HDBK-978A (NASA), 
Volume II, Section 18 (Except 18.3 and 18.4). Analysis of cable/ 
wiring to verify requirements of SLP 2104 para 7.4 (if 
applicable) . 

(b) Inspection of as-built hardware. 

2 . Crew procedure for equipment power down or design review and QA 
certification of sealed components. 

STATUS OF VERIFICATION: 

Phase I - (Provide a tentative schedule for completion of each 
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Phase II 


verification analysis and inspection.) 

- {Specify schedule for the completion of each verification 
analysis, inspection, and certification.) 

Phase III - (All Safety verification should be complete. Briefly 

summarize the results of the completed analyses, inspections, 
and QA certification and refer to particular analysis reports 
by document number and title. All open verifications shall 
be identified.) 


APPROVAL 
PHASE I 
PHASE II 
PHASE III 


PAYLOAD ORGANIZATION 


STS 


Press #fyellow SPACE#d to continue. ') . 
column = ? column - 1. 
row = ?row - 1. 
close_window ( ) . 
end. (*fire*) 


topic 'RADIATION'. 

column = ? column + 1. 


row = ?row + 1. 
window ('RADIATION' 
say (' 

PAYLOAD : 

SUBSYSTEM: Electrical 
HAZARD GROUP: Radiation 


, blue, white, white, ?column, ?row, 74,15) . 

PAYLOAD HAZARD REPORT 

PHASE 

DATE 9-10-86 


TITLE: Exposure of the STS electrical system or other payloads to EMI 


| NO. G 


APPLICABLE SAFETY REQUIREMENTS: 
NHB 1700.7, paragraph 206, 212.2 
DESCRIPTION OF HAZARD: 


HAZARD CATEGORY 


X 


Catastrophic 

Critical 


Payload generated EMI in excess of allowable limits interferes with 
Orbiter and/or other payload operations. 


HAZARD CAUSES: 

Radiated or conducted EMI from payload elements caused by electrical 
switching and/or equipment operation. 


HAZARD CONTROLS: 

Payload equipment will be (has been) designed for compliance with 
MSFC-SPEC-521 or equivalent requirements. Equipment conducted and 
radiated emissions will (does) not exceed the levels specified in 
MSFC-SPEC-521. 


SAFETY VERIFICATION METHODS: 

Test for radiated and conducted emissions in accordance with 
MSFC-SPEC-521 . 

STATUS OF VERIFICATION: 

Phase I - (Provide a tentative schedule for completion of the EMI 
tests . ) 
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Phase II - (Specify schedule for the completion of the EMI tests.) 

Phase III - (All safety verification should be complete. Briefly 

summarize the results of the completed tests and refer to 
particular test reports by document number and title. All 
open verifications shall be identified.) 


APPROVAL 
PHASE I 
PHASE II 
PHASE III 


PAYLOAD ORGANIZATION 


STS 


Press #f yellow SPACE#d to continue. ') . 
column = ? column - 1. 
row = ?row - 1. 
close_window ( ) . 
end. (*radiation*) 
end. (*electrical* ) 


topic 'HUMAN FACTORS'. 

column = ? column + 1. 
row = ?row + 1. 

window ('HUMAN FACTORS ', blue, white , white , ?column, ?row, 74 , 16 ) . 


say ( ' 

PAYLOAD HAZARD REPORT NO. G-4 

PAYLOAD : PHASE 

SUBSYSTEM: Human Factors DATE 9-10- 

HAZARD GROUP: Injury/Illness 

TITLE: Exposure of crew to sharp corners, edges or protrusions 


86 


APPLICABLE SAFETY REQUIREMENTS: 
NASA-STD-3000 , paragraphs 6.3.3 and 14.1.3 


HAZARD CATEGORY 


X 


Catastrophic 

Critical 


DESCRIPTION OF HAZARD: 

Injury of personnel caused by contact with sharp edges, corners, or 
protrusions . 


HAZARD CAUSES: 

Hardware designed and/or manufactured with sharp edges, corners, or 
protrusions . 

HAZARD CONTROLS: 

Hardware will be (has been) designed to comply with the intent of 
NASA-STD-3000, Volume I, paragraph 6.3.3 (and paragraph 14.1.3 for 
payload bay equipment on EVA missions) . 

NOTE TO PED : 

For planned EVA Missions, this hazard report should be identified 
as catastrophic . 

SAFETY VERIFICATION METHODS: 

1. Drawing review for inclusion of requirements to remove sharp 
corners and edges or to provide protective covers . 

2. QA certification that as-built hardware conforms to the drawings. 
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STATUS OF VERIFICATION: 

Phase I - (Provide a tentative schedule for completion of QA 
inspection. ) 

Phase II - (Specify schedule for the completion of QA inspection.) 

Phase III - (All safety verification should be complete. Briefly 
summaize the results and actual dates of the completed 
inspections and refer to particular inspection certifications 
provided. All open verifications shall be identified. 


APPROVAL 
PHASE I 
PHASE II 
PHASE III 


PAYLOAD ORGANIZATION 


STS 


Press #f yellow SPACE#d to continue. '). 
column = ? column - 1. 
row = ?row - 1 . 
close_window ( ) . 
end. (* human factors*) 

topic 'MATERIALS' . 

typeMlist = ['INJURY/ILLNESS', 

'FIRE' , 

'QUIT' ] . 
typeMans = ' ' . 
column = ? column + 1. 
row = ? row + 1 . 

window ('MATERIALS - GENERIC FLIGHT HAZARDS ', blue , white , white , 
?column, ?row, 74 , 15) . 
while ? typeMans <> 'QUIT' 
then 
ask ( ' 

Which Hazard Group would you like to view? ', typeMans, ? typeMlist) 
and 

if ? typeMans = ' INJURY/ ILLNESS' 
then 

do ( ' INJURY/ ILLNESS' ) 

else 

if ?typeMans = 'FIRE' 
then 

do ('FIRE' ) 

else 

if ?typeMans = 'QUIT' 
then 

column = ? column - 1 
and 

row = ?row - 1 
and 

close_window () . 
topic ' INJURY/ ILLNESS ' . 
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column = ?column + 1 . 


row = ?row + 1. 

window ( ' INJURY/ ILLNESS' , blue , white, white, ?column, ?row, 74,15) 


PAYLOAD HAZARD REPORT 

PHASE 


say ( ' 

PAYLOAD : 

SUBSYSTEM: Materials 
HAZARD GROUP: Injury/Illness 

TITLE: Toxic offgassing materials in habitable areas 


DATE 9-10-86 


| NO. G 


APPLICABLE SAFETY REQUIREMENTS: 
NHB 1700.7, paragraph 209.3 


HAZARD CATEGORY 
Catastrophic 
Critical 


DESCRIPTION OF HAZARD: 

Toxic constituents of offgassing materials used in habitable areas 
cause temporary of permanent crew injury/illness . 


HAZARD CAUSES: 

Use of materials which offgas toxic gases or other by-products. 


NOTE TO PED: 

The use of toxic substances requiring containment should be 
documented in unique hazard reports . 


HAZARD CONTROLS: 

1. Materials will be (have been) selected in accordance with 
MSFC-HDBK-527/JSC 09604. A Materials Usage Agreement (MUA) 
will be (has been) submitted for materials having less than 
an "A" or "K" rating as defined in MSFC-HDBK-527/JSC 09604. 

2. Equipment /hardware will be (has been) built in conformance 
with approved materials lists. 

3. Payload assembly (s) will be (have been) offgas tested and 
test data will be (has been) submitted to MSFC in accordance 
with Test 16 of NHB 8060.1. 


SAFETY VERIFICATION METHODS: 

1. Materials list will be (have been) submitted to MSFC Materials 
and Processes Laboratory for approval . 

2. QA certification that as-built configuration is in accordance 
with design drawings and parts lists. 

3. MSFC evaluation of offgassing test data. 

STATUS OF VERIFICATION: 

Phase I - (Provide a tentative schedule for completion of each 
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Phase I I 


verification test or data submittal.) 

- (Specify schedule for the completion of each verification 
test or data submittal . ) 

Phase III - (All safety verification should be complete. Briefly 
summaize the results of the completed tests and data 
evaluations. Refer to particular test reports by document 
number and title. All open verifications shall be 
identified. ) 


APPROVAL 
PHASE I 
PHASE II 
PHASE III 


PAYLOAD ORGANIZATION 


STS 


Press #fyellow SPACE#d to continue. ') . 
column = ? column - 1. 
row = ?row - 1. 
close_window ( ) . 
end. (*injury/illness*) 


topic ' FIRE' . 

column = ?column + 1. 
row = ?row + 1. 

window (' FIRE' , blue, white, white , ?column, ?row, 74 , 15) . 
say (' PAYLOAD HAZARD REPORT 


PAYLOAD : 

SUBSYSTEM: Materals 

HAZARD GROUP: Fire 

TITLE: Use of flammable materials 


PHASE 

DATE 9-10-86 


r\ 


| NO. G- 


APPLI CABLE SAFETY REQUIREMENTS: 
NHB 1700.7 paragraph 209.2 


HAZARD CATEGORY 


X 


Catastrophic 

Critical 


DESCRIPTION OF HAZARD: 

Fire with heat and smoke causes injury/illness of crewmember, and 
possible equipment damage or malfunction. 

HAZARD CAUSES: 

The use of flammable materials in proximity to an ignition source 
could result in a fire or propagation of a fire. 

NOTE TO PED: 

The use of flammable liquids and gasses should be discussed in 
unique hazard reports . 

HAZARD CONTROLS: 

1. Non-metallic materials will meet (have met) the requirements 
of NHB 1700.7 and NHB 8060.1 as required. Materials will be 
(have been) selected in accordance with MSFC-HDBK-527/JSC 09604, 
Table 2. For each material having less than an "A" rating, 
a Materials Usage Agreement (MUA) will be (has been) submitted 
to the MSFC Materials and Processes Laboratory for approval. 

SAFETY VERIFICATION METHODS: 

1. Materials lists and MUAs will be (have been) submitted to 
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MSFC Materials and Processes Laboratory for approval . 

2. QA certification that the as-built configuration is in 
accordance with design drawings and parts lists. 

STATUS OF VERIFICATION: 

Phase I - (Provide a tentative schedule for materials data submittals. 

Phase II - (Provide materials data submittal schedule.) 

Phase III - (All Safety verification should be complete. Briefly 
summarize the results of the materials data evaluations 
and certifications. Refer to particular QA certifications. 

All open verifications shall be identified.) 


APPROVAL 
PHASE I 
PHASE II 
PHASE III 


PAYLOAD ORGANIZATION 


STS 


Press #fyellow SPACE#d to continue. '). 
column = Pcolumn - 1 . 
row = ?row - 1. 
close_window ( ) . 
end. (*fire*) 
end. (*Materials*) 


topic 'STRUCTURES'. 

column = ? column + 1 . 
row = ?row + 1. 

window ('STRUCTURES' , blue, white, white, ?column, ?row, 74 , 16) 
say (' PAYLOAD HAZARD REPORT 


PAYLOAD : 

SUBSYSTEM: Structures 
HAZARD GROUP: Collision 

TITLE: Structural failure due to launch, flight, and landing 
environments or stress corrosion cracking. 


PHASE 

DATE 9-10-86 


APPLICABLE SAFETY REQUIREMENTS: 

NHB 1700.7, paragraphs 208.1, 208.2, and 208.3 


HAZARD CATEGORY 
Catastrophic 
Critical 


DESCRIPTION OF HAZARD: 

Failure of payload structural elements or attachment hardware results 
in unrestrained objects in the Spacelab module, Orbiter or Payload 
Bay which could impact Orbiter, Spacelab or other payloads. 


HAZARD CAUSES: 

1 . Structural elements of payload equipment lack structural strength 
to withstand launch, landing, and emergency landing loads, 
on-orbit environments (including depressurization and 
repressurization), or fail because of pre-existing flaws. 


NO. G- 
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2. The use of structural materials which are susceptible to stress 
corrosion cracking. 

3. Structural elements improperly manufactured or manufactured using 
unacceptable materials. 


HAZARD CONTROLS: 

1. a. Safety critical structures design will be (has been) based on 
worse-case mission induced loads with no negative margins of 
safety. Metallic structures design will be based on factors 
of safety of 2.0 ultimate and 1.25 yeild on untested structure, 
or 1.4 ultimate and 1.1 yield on structures qualified by static 
load tests. Non-metallic (including composites) structure 
design will be (has been) based on a factor of safety of 1.4 
and 2.0 ultimate, where the higher factor will be (has been) 
used in joint (discontinuity) areas. All design and tests 
will be in accordance with MSFC PPO document number JA-418. 

b. The design will be (has been) based on fracture control 
procedures for safety-critical structures in accordance 
with JA-418 . 


HAZARD CONTROLS: (continued) 

c . Positive locking for threaded fasteners in safety critical 
structures for module center aisle, SMIDEX, and pallet 
mounted equipment will be (has been) provided. 

2 . Materials will be (have been) selected in accordance with 
MSFC-SPEC-522 , Table I, or a Materials Usage Agreement (MUA) 
will be (has been) submitted to the MSFC Materials and 
Processes Laboratory for approval . 

3. Safety critical structures will be (have been) built in 
accordance with approved design drawings and parts lists. 

SAFETY VERIFICATION METHODS: 

1. a. Structural analysis to verify positive margins against 

specified factors of safety and static load test for 
safety factors < 2.0 ultimate. 

b. MSFC Fracture Control Board review and approval of fracture 
control plan and fracture mechanics analysis (including NDE) . 

c. Inspection verifying positive locking devices are in place, 

or vibration testing showing no fastener back-off in accordance 
with MSFC- STD- 5 61 criteria. 

2. Approval of Metallic Materials List and MUAs by MSFC Materials 
and Processes Laboratory. 

3. QA certification that as-built hardware is in accordance with 
design drawings and parts lists as approved for safety critical 
structures . 

STATUS OF VERIFICATION: 

Phase I - (Provide a tentative schedule for completion of each 
verification test, analysis, and/or inspection.) 
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Phase II - (Specify schedule for the completion of each verification 
test, analysis, or inspection.) 

Phase III - (All safety verification should be complete. Briefly 
summaize the results of the completed tests, analyses, 
and/or inspections and refer to particular test/analysis 
reports by document number and title. Provide actual 
completion date or test(s). Based on stress analyses, 
provide a summary table which shows the minimum margins 
of safety for safety critical structures. All open 
verifications shall be identified. 


APPROVAL 
PHASE I 
PHASE II 
PHASE III 


PAYLOAD ORGANIZATION 


STS 


Press #f yellow SPACE#d to continue . ' ) . 
column = ? column - 1 . 
row = ?row - 1. 
close_window ( ) . 
end. (* structures*) 
end. (*fligthaz*) 

topic 'groundhaz' . 

sub2option = ['ELECTRICAL', 

' STRUCTURES ' , 

'PRESSURE' , 

'QUIT' ] . 

sub2choice = ' ' . 
column = ? column + 1. 
row = ?row + 1. 

window ('GENERIC GROUND HAZARDS' , blue , white , white, ?column, ?row, 73 , 16 ) . 
while ?sub2choice <> 'QUIT' 
then 

ask ( ' #e 

Which Flight Hazard Report Subsystem do you wish to view?', sub2choice, 
?sub2option) 
and 

if ?sub2choice = 'ELECTRICAL' 
then 

do ('ELECTRICAL') 

else 

if ?sub2 choice = 'STRUCTURES' 
then 

do ('STRUCTURES') 

else 

if ?sub2choice = 'PRESSURE' 
then 

do ('PRESSURE') 

else 

if ?sub2choice = 'QUIT' 
then 
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column = ? column - 1 
and 

row = ?row - 1 
and 

close window () . 


topic 'ELECTRICAL'. 

column = ?column + 1. 


row = ?row + 1 . 


window (' ELECTRICAL' , blue, white , white , ’column, ?row, 74 , 16) . 


say ( ' 

PAYLOAD HAZARD REPORT 

PAYLOAD : 

SUBSYSTEM: Electrical 
HAZARD GROUP: Injury/Illness 
TITLE: Electrical Shock 


NO. KG-1 
PHASE 

DATE 9-16-86 


APPLICABLE SAFETY REQUIREMENTS: 
NHB 1700.7, paragraph 4.3.2 


HAZARD CATEGORY 


X 


Catastrophic 

Critical 


DESCRIPTION OF HAZARD: 

Electrical shock to ground operations personnel could result from 

contact with high voltage sources associated with Ground Support 

Equipment (GSE) . 

HAZARD CAUSES: 

1. High voltage sources accessible to the ground crew. 

2 . Equipment inadequately bonded/grounded which allows exposed 
surfaces of equipment to have potential voltages above ground. 

HAZARD CONTROLS: 

1. High voltages will be (are) inaccessible to the crew or interlocks 
will be (have been) provided to remove power. Equipment will be 
(has been) designed to requirements of JA-077 and KHB 1700.7, 
paragraph 4.3.2. 

2. Equipment, including surfaces, will be (has been) grounded and 
the ground connected to facility ground. 


SAFETY VERIFICATION METHODS: 

1. Design review, and test of interlocks. 

2. Design review and test. 

STATUS OF VERIFICATION: 

Phase I - (Provide a tentative schedule for completion of each 
verification test.) 

Phase II - (Specify schedule for the completion of each verification 
test . ) 

Phase III - (All safety verification should be complete. Briefly 

summarize the results of the completed tests, provide actual 
date of test completion, and refer to particular test reports 
by document number and title. All open verifications shall 
be identified.) 
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DESCRIPTION OF HAZARD: 

Failure or improper use of handling devices and slings cause injury 
to ground crew and/or equipment damage. 

HAZARD CAUSES: 

1. Inadequate design of handling devices and slings. 

2 . Degradation and/or structrual failure of equipment 

3 . Improper use of equipment or inadequate procedures . 

HAZARD CONTROLS: 

1. Handling devices and slings are (will be) designed, built, and 
tested to meet requirements of KHB 1700.7, paragraph 4.5. 

Design is (will be) based on safety factors 5.0 ultimate and 
3.0 yield, and equipment has been (will be) proof-tested to 2 
x rated load. Synthetic slings will be (have been) designed 
and tested to requirements of KHB 1700.7, Table 4-1. See 
#matt ached table#m. 

NOTE TO PED: 

Provide line drawings of handling equipment and fill in the 
attached table. 

2. Handling devices will be checked before each usage. 

Arrangements have been (will be) made for periodic inspection 
of equipment per KHB 1700.7. 

3 . Handling devices will be operated by using KSC approved 
handling procedures. 
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SAFETY VERIFICATION METHODS: 

1. Stress/Design analysis. 


2. QA certification of proof load test of handling equipment. 

3. QA certification of inspections and re-proof tests. 

4. Procedures to be submitted to MSFC. Procedures have been 
(will be) submitted to KSC with equipment. Procedure 
numbers have been (will be) identified on the hazard report 
(Phase III) . 

STATUS OF VERIFICATION: 

Phase I - (Provide a tentative schedule for completion of proof - 
load testing, analysis, and inspection.) 

Phase II - (Specify schedule for the completion of proof -load 
testing, analysis, and inspection.) 

Phase III - (All safety verification should be complete. Briefly 
summarize the results of the completed tests, analyses, 
and/or inspections and provide actual date of test(s) 
completion. Refer to particular test /analysis reports 
by document number and title. All open verifications 


shall 

be 

identified. ) 


APPROVAL 
PHASE I 

PAYLOAD ORGANIZATION 

STS 

PHASE II 



PHASE III 





Press #fyellow SPACE#d to continue. ') 

i . 


topic 'attached table', 
column = ?column + 1 . 
row = ?row + 1. 

window ('SUPPORT DATA - PHR KG- 2- GROUND HANDLING EQUIPMENT', 
blue, white, white, ?column, ?row, 74,16) . 
say (' 


Desig- 

nation 

Number 

Item 

Name 

Sid 

0 

M 

mg 

L) 

S 

Crd 

(S 

Y 

it 

2) 

N 

Rated 

Load 

(LBS) 

Ultimate 

Load 

(LBS) 

Proof 

Load 

(LBS) 

Actual 

Load 

(LBS) 

Verf . 
Status 





























- 




























NOTES: 1. Identify whether slings are metallic or synthetic by placing 

an "X" in the appropriate column. For synthetic slings 
include the type of sling material in the name column, and 
see Table 4-1 of KHB 1700.7 for the required safety factors 
and proof load test criteria. 
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2. Denote whether the device has a critical weld by placing an 
"X" in the appropriate column. If there are critical welds, 
other tests may be applicable (see KHB 1700.7, paragraph 
4. 5. 1.1 D) . A critcal weld is a weld which constitutes a 
single point or failure. Where feasible, critical welds 
should be eliminated. 


Press #fyellow SPACE#d to continue. '). 
column = ?column - 1. 
row = ?row - l . 
close_window ( ) . 
end. (*attached table*) 
column = ?column - 1 . 
row = ?row - 1 . 
close_window ( ) . 
end. (*structures*) 


topic 'PRESSURE'. 

column = ?column + 1 . 


row = ?row + 1 . 


window (' PRESSURE' , blue, white, white, ?column, ?row, 74, 16) . 


say ( ' 


PAYLOAD HAZARD REPORT 


PAYLOAD : 

SUBSYSTEM: Pressure 
HAZARD GROUP: Explosion 
TITLE: Pressure Systems 


NO. KG- 3 
PHASE 

DATE 9-16-86 


APPLICABLE SAFETY REQUIREMENTS: 
KHB 1700.7, paragraph 4.3.3. 


HAZARD CATEGORY 
Catastrophic 
Critical 


DESCRIPTION OF HAZARD: 

Injury to ground crew or damage to equipment resulting from 
failure of pressurized system elements or components during 
ground operations . 

HAZARD CAUSES: 

1. Improper design of flight and ground pressure system elements 
and components resulting in structural failure, explosion, or 
rupture of components, lines, or fittings. 

2 . Improper use of equipment or inadequate procedures . 

HAZARD CONTROLS: 

1. a. Flight pressure systems will be (have been) designed to 
requirements of NHB 1700.7 Chapter 2. 

NOTE TO PED: 

Reference the applicable unique flight hazard report here. 

b. Pressure vessels used in GSE will be (have been) designed 
to the ASME Boiler and Pressure Vessel Codes, Section VIII, 
Division I or Division II as applicable. 

NOTE TO PED: 

Identify applicable division. 
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c. Pressure system components (except pressure vessels) will 
be (have been) designed to a burst pressure level of at 
least 4 times (safety factor 4.0 ultimate) the maximum 
operating pressure (MOP) . See #mattached table#m. 

d. Regulators, gages and pressure relief devices will be 
(have been) sized and provided to protect down stream 
equipment including flight hardware. (See KHB 1700.7 
paragraph 4 . 3 . 3 . 1 . 3 ) . 

e. Pressure systems will be (have been) designed such that 
pressures cannot be trapped in any part of the system 
without bleed capability. 

f. Pressure systems will be (have been) proof pressure tested 
to 1.5 X Maximum Operating Pressure. 

2 . System will be operated in accordance with approved precedures . 

NOTE TO PED: 

Attach a simplified pressure system schematic which specifies 
pressure relief device settings, flow rates, and denote the 
type of fluid. Provide the appropriate design information 
of each type of system component on the attached table . ) 

SAFETY VERIFICATION METHODS : 

1. a. Verified through flight safety panel phased safety reviews. 

b. Stress analysis and qualification test as required. 

c. Stress analysis or certification of design criteria or 
purchased components . 

d. Design review and analysis. 

e. Design review. 

f . Proof pressure test to 1.5 X MOP of assembled equipment 
system. 

2. Operating procedures will be (have been) submitted to MSFC. 

NOTE TO PED: 

Precedure numbers to be identified on the Phase III hazard 
report . 

STATUS OF VERIFICATION: 

Phase I - (Provide a tentative schedule for completion of each 
verification test and analysis.) 

Phase II - (Specify schedule for the completion of each verification 
test and analysis . ) 

Phase III - (All safety verification should be complete. Briefly 

summarize the results of the completed tests, and analyses, 
provide actual date of test(s) completion, and refer to 
particular test and analysis reports and procedures by 
document number and title . Attach a summary of the Pressure 
Vessel/System Log Book. The Phase III log summary shall state 
maximum operating pressue, proof pressure, burst pressure, 
number of cycles above threshold, number of cycles above 
maximum operating pressure, design cycle limit, maximum 
level of which vessel was pressurized, and date of proof test. 
All open verifications shall be identified.) 
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PAYLOAD ORGANIZATION 


STS 


APPROVAL 
PHASE I 
PHASE II 

PHASE III 

Press #fyellow SPACE#d to continue. ' j. 

topic 'attached table'-, 
column = ? column + 1 . 
row = ?row + 1. 
window ( 

'SUPPORT DATA - PAYLOAD HAZARD REPORT KG- 3- PRESSUREIZED SYSTEMS', 
blue, white, white, ?column, ?row, 74,16) . 
say ( ' 


COMPONENT 

NUMBER 

COMPONENT 

NAME 

DESIGN 

PRESSURE 

(PSI) 

BURST 

PRESSURE 

(PSI) 

SYSTEM 

WORKING 

PRESSURE 

(PSI) 

COMPONENT 

PROOF 

PRESSURE 

(PSI) 

VERF. 

STATUS 





































DEFINITIONS : 

1 . Design Pressure - The maximum design operating pressure of the 

component . 

2. Burst Pressure - The component design burst pressure. 

3 . System Working Pressure - The working pressure as used in the 

system. 

4. Component Proof Pressure - 1.5 maximum operating (working) 

pressure . 

Press #fyellow SPACE#d to continue. ') . 
column = ?column - 1. 
row = ?row - 1 . 
close_window ( ) . 
end. (*attached table*) 
column = ? column - 1 . 
row = ?row - 1. 
close_window ( ) . 
end. (*pressure*) 

end. ( *groundhaz*) 

end. (*Appendix B*) 
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(*APPDC.KB This is a subprogram to display the unique hazard reports found 
in appendix c of JA-012. *) 

column = 3 . 
row = 3 . 

do ( ' Appendix C ' ) . 
topic 'Appendix C' . 

window ('SAFETY COMPLIANCE DATA PACKAGE' , blue , white , white , ?column, ?row, 
76,18) . 

column = ?column + 1 . 
row = ?row + 1 . 

window ('Appendix C' , blue, white, white, ?column, ?row, 74, 17) . 
say ( ' #e 

UNIQUE HAZARD REPORTS 

During the performance of the payload element (including experi- 
ments) hazards analyses, it is highly probable that hazards that 
do not fall into the category covered by generic hazard reports 
will be identified. These hazards are generally peculiar to a 
particular instrument /experiment , or the hazard controls vary 
significantly from other payload elements. These hazards are 
identified and documented as unique hazard reports and should be 
designated with a unique report number. 

A tabulation of several hazard titles has been developed and is 
presented as an aid to the PED in developing the safety data. 

These titles are provided in #mTable C-l#m for flight hazards and 
#mTable C-2#m for ground hazards. 

' To further assist the PED in understanding the type of backup 
information required for safety data, two examples of unique 
flight hazard reports have been provided in a Phase III 
configuration. These hazard reports relate to pyrotechnic 
release devices and a high-pressure gas system. The backup 
information is typical of the data required for hazard report 
closure . 

There is one unique flight hazard report that must be submitted 
for each item of payload equipment, if applicable. This report 
deals with the loss of the payload cooling medium (Freon, water, 
rack air, cabin air, etc.) and us titled "Loss of Cooling." This 
is not categorized as a generic hazard because of the wide range 
of control and verification options which make such an inclusion 
impractical. The category itself can be "critical" for some 
designs and "catastrophic" for others, depending upon the hazard 
potential. Controls can range from no special controls, if 
cooling loss can be verified not to be a hazard, to a redundant 
set of automatic power cutoff equipment for a design with 
catastrophic hazard potential. 

Press ifyellow SPACE#d to continue . ' ) . 


sublchoice = ' ' . 

subloption = [ ' PYROTECHNICS' , ' PRESSURE SYSTEMS' , ' QUIT' ] . 
column = ?column + 1 . 
row = ? row + 1 . 

window ('UNIQUE FLIGHT HAZARDS' , blue, white, white, ?column, ?row, 73, 16) . 
while ? sublchoice <> 'QUIT' 
then 

ask ( ' #e 
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Which Unique Flight Hazard Report do you wish to view?' , sublchoice, 
?subloption) 
and 

if ?sublchoice = 'PYROTECHNICS' 
then 

do ( ' PYROTECHNICS ' ) 

else 

if ? sublchoice = 'PRESSURE SYSTEMS' 
then 

do ('PRESSURE SYSTEMS') 

else 

if ?sublchoice = 'QUIT' 
then 

new_kb ( ' PHOFLDOC . HKB ' ) . 

topic 'Table C-l' . 

column = ?column + 1. 
row = ?row + 1 . 

window ('TABLE C-l' , blue, white, white, ?column, ?row, 72, 16) . 
say ( ' #e 

EXAMPLES OF UNIQUE FLIGHT HAZARD TITLES 

This section lists titles in both areas. 

Please select the most appropriate one . 

tmORBITER MIDDECK OR SPACELAB MODULE #m 


#mORBITER PAYLOAD BAY#m 


Press #f yellow SPACE#d to continue . ' ) . 

topic 'ORBITER MIDDECK OR SPACELAB MODULE', 
say ( ' #e 

Exposure of Crew to Broken Glass or Frangible Materials 
Release of Toxic or Noxious Gas into Habitable Atmosphere 
Containment of Flammable Fluids 
Frangmentation or Failure of Rotating Equipment 
Explosion/Rupture of Batteries 
Contamination Because of Battery Electrolyte Leakage 
Electrical Shock from Biomedical Instrumentation System 
Improperly Stowed Equipment 
Untethered Experiment Apparatus 
Hazardous Touch Temperatures 
Exposure of Crew to Pathogenic Micro-Organisms 
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Containment of . Stowed Energy; e.g. f Springs 
Explosion/Rupture of Pressure Systems 
Contamination Because of Release of Mercury 
Failure of Vacuum Venting Results in Loss of Orbiter/Module Atmosphere 

Use of Toxic Materials 

Eye Injury As A Result of Exposure to Laser or Other High- Intensity 

Light (Nonionizing Radiation) 

Overtemperature/Fire Resulting from Runaway Furnaces or Heaters 

Loss of Cooling 

Impediment for Emergency Egress of the Crew From the Module 

Inability to Restow/Relatch Experiment Equipment during Emergency 

Evacuation 

Use of Radioactive Materials 

Containment of Toxic Experiment Samples 

Press #fyellow SPACE#d to continue. '). 

end. (*ORBITER MIDDECK OR SPACELAB MODULE*) 

topic 'ORBITER PAYLOAD BAY', 
say ( ' #e 

Battery - Explosive Rupture /Leakage 
Collision Caused by Unsecured Hardware (e.g.. Covers) 
Explosion/Implosion of Experiment Container 
Use of Radioactive Materials 

Explosion/Rupture of Pressure Systems (Including Heat Pipes) 
Collision Because of Experiment Pointing System Failure 
Cryogen Storage Tank Overpressurization 
Collision Because of Experiment Restraint Latch Failure 
Collision Among Payload Elements During RMS Operations 
Fire/Damage Becasue of High-Energy Laser; also Crew Exposure 
Premature Deployment of Mast (or other Deployable Elements) 
Premature Actuation of Pyrotechnic or other Release Devices 
Inability to Restow Deployable Payloads 
Inability to Clear Payload Bay Doors 
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Release of Mercury into the Payload Bay 
Loose Equipment Jams Payload Bay Door Closure Mechanism 

Eye Damage Because of Improper Positioning of Reflecting Lasers 
Contamination Resulting from Release of Corrosive Materials 
Contact or recontact with the Orbiter or Deployed Payload Equipment 


Press #fyellow SPACE#d to continue. '). 
end. (*ORBITER PAYLOAD BAY*) 

column = ? column - 1. 
row = ?row - 1. 
close_window () . 
end. (*Table C-l*) 

topic 'Table C-2'. 

column = ? column + 1. 
row = ?row + 1 . 

window ('TABLE C-2' , blue, white, white, ?column, ?row, 72, 16) . 
say ( ' #e 

EXAMPLES OF UNIQUE GROUND HAZARD TITLES 

Use of Radioactive Materials 

Release of Toxic Gases during Ground Operations 

Use of Laser /High- Intensity Light that could Casue Eye Damage 

Oxygen Displacement in Confined Areas 

Containment and Handling of Cryogenic Fluids 

Use of Spark (Ignition) Sources in Equipment Adjacent to Orbiter or 

Propellant Systems 

Explosion/Rupture of Batteries 

Containment of Mercury 

Handling/Operations using Biological Specimens 
Use of Flammable Fluids during Ground Operations 
Premature Actuation of Pyrotechnic Devices 
Exposure of Ground Crew to Rotating Devices 


Press #f yellow SPACE#d to continue. '). 
column = ?column - 1. 
row = ?row - 1 . 
close_window () . 
end. (*Table C-2*) 
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topic 'PYROTECHNICS', 
column = ?column + 1. 
row = ?row + 1 . 

window (' PYROTECHNICS' , blue, white , white, 3 , ?row, 74 , 16) . 
say ( ' #e 


PAYLOAD HAZARD REPORT 
PAYLOAD: Automated Celestial Telescope 
SUBSYSTEM: Pyrotechnics 
HAZARD GROUP: Collision 

TITLE: Inadvertent Actuation of Pyrotechnics 


NO. ACT-1 
PHASE III 
DATE 10-15-86 


APPLICABLE SAFETY REQUIREMENTS: 
NHB 1700.7, paragraph 210 


HAZARD CATEGORY 
Catastrophic 
Critical 


DESCRIPTION OF HAZARD: 

Inadvertent actuation (premature firing) of pyrotechnics causes 

release of experiment hardware in cargo bay. 

HAZARD CAUSES: 

Inadvertent actuation of pyrotechnics. 

1. Operator error. 

2. Multiple circuit failures. 

3. EMI actuation. 

4. Lightning (static electric discharge). 

5. Use of non-approved initiators. 

6 . Bent pins in power and control circuit connectors . 

HAZARD CONTROLS: 

1. The design includes a minimum of three inhibits to pyrotechnic firing 
and requires that three switches be actuated sequentially to fire 
the pyrotechnic squibs for the primary system and three switches 

for the backup squibs. Two of these switches are lever lock 
positive actuation which use switch guards to preclude inadvertent 
operation. The control panel is provided with indicator lights 
on each relay to indicate that the relays are open (SAFE) . 

2 . Power to the squibs is supplied through three series relays and 
the squibs are short circuited until the fire relay is actuated. 

3. Pyrotechnic circuits are designed to MIL-STD-1512 requirements. 

Cables are schielded and there is a short circuit across the 
pyrotechnic NSI initiators until fire relay is actuated. 

4. Control relays are enclosed in a metallic box and grounded. The 
experiment is enclosed by the payload bay doors . 

5. The design uses approved NSI type intiators. 


SAFETY VERIFICATION METHODS: 

1. Design Review. Test indicator lights during system level tests 
with Orbiter. 

2. Design Review. 

3 . Separation system qualification test and acceptance test of 
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pyrotechnics circuitry for short across NSI initiators, and 
to verify shielding. Design review of shield attenuation. 

4. Inspect enclosure of relays and verify grounding of box. 

Analysis to show pyrotechnics will not fire with lightning 
(static electric discharge) . 

5. Record serial number and acceptance test data on each NSI used 
for flight. 

6. MSFC Procedure 924 dated June 13, 1983 will verify prior launch 
that there are no pin-to-pin shorts in the pyrotechnic lines 
that could result in short during launch. Bent pin analysis and 
test at KSC. 

STATUS OF VERIFICATION: 

1. CLOSED. See attached #m"Normal Pyrotechnic Operation" #m. Design 
review completed 7-1-86. System test satisfactory (11-5-86). 

See attached test summary. 

2. CLOSED. See #mattached supporting data#m. Review completed 7-1-86. 

3. CLOSED. See attached #m" Separation System Test Summary"#m. 

4. CLOSED. Lightning static electric discharge analysis has been 
completed. See #mattached letter#m. 

5. CLOSED. Serial number and acceptance test data on each NSI used 
for flight will be recorded when issued at KSC. 

6. CLOSED. Bent pin analysis is in attached, TBE memorandum 
PMIC- INT-P341-007 (84) dated January 11, 1985 and GIRD specifies 
MSFC procedure 924 for testing of pyrotechnic circuits for shorts. 


APPROVAL 

PHASE I 
PHASE II 
PHASE III 


PAYLOAD ORGANIZATION 


STS 


Press #f yellow SPACE#d to continue. ' ) . 

topic '"Normal Pyrotechnic Operation"', 
column = ? column + 1 . 
row = ?row + 1 . 

window (, blue, white, white, ?column, ?row, 74 , 16) . 
say ( ' #e 

NORMAL PYROTECHNIC OPERATIONS 

The design provides cross strapping of power supplies to the 
pyrotechnic controls in order to eliminate single point failures 
which could defeat the two- failure tolerance criteria for CTOL 
release. This design requires three distinct switch operations 
on the Deployment/Pointing Panel (Figure ACT-1-1) to fire either 
the primary squibs or the backup squibs. In order to fire the 
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primary pin pullers, the rotary separation switch (SI) on the 
Deployment Pointing Panel (DPP) depicted in Figure ACT-1-1, must 
be repositioned to "No.l Primary", the Arm/Safe Switch (S2) 
positioned to "ARM", and then the Deploy/Safe Switch (S3) is 
positioned to the "Deploy" position. These three switch operations 
actuate three series relays which normally interrupt power to the 
squib. The third switch/relay operation also removes the normal 
short circuit across the squib. The short circuit normally across 
each squib is to preclude operation from EMI. After operation 
of the #1 primary squib, the #2 primary squib must be fired. 

This operation is accomplished by moving the rotary switch on the 
DPP from "#1 Primary" to "#2 Primary" and positioning the Arm/Safe 
and Deploy/Safe switches as discussed for firing "#1 Primary" . 

Firing of the redundant pyrotechnic pin pullers is accomplished in 
the same manner as used to fire the primary 1 and 2 pin pullers 
except that the rotary switch is positioned to "#1 Redundant" and 
"#2 Redundant" . Successful release of the ACT CTOL requires 
operation of a #1 pyrotechnic and a #2 pyrotechnic in any combination 
of primary and/or redundant pin pullers. Figure ACT-1-2 provides 
a schematic of the fusing circuit while Figure ACT- 1-3 provides a 
simplified schematic of the pyrotechnic firing circuits. 

Instrumentation has been incorporated to provide the operator with 
visual indication of firing accomplishment . Two indicators are 
provided on the control panel to indicate when the Primary or 
Redundant Arm switches and their corresponding relays have been 
actuated. These indicators, normally red and white barber pole, will 
swithc to gray when the system is armed. The control panel is also 
equipped with two indicators to show when the clamps have been 
operated (successful firing of a pin puller operates a clamp) . 

Both indicators switch from barber pole to gray when the #1 and #2 
clamps are released. When both clamps are released, the CTOL is 
free and can be separated. The relays and lights are depicted in 
Figure ACT- 1-4 (Pyro Control) . 

Press #fyellow SPACE#d to continue. ') . 
column = ? column - 1. 
row = ?row - 1. 
close_window() . 

end. (* "Normal Pyrotechnic Operation"*) 

topic '"Separation System Test Summary"', 
column = ? column + 1. 
row = ?row + 1 . 

window (, blue, white, white, ?column, ?row, 74 , 16) . 
say ( ' #e 

SEPARATION SYSTEM TEST SUMMARY 

The test data, contained in the Test Procedure (Appendix A) in 
Tables II and IV of ACT-6-2421, is summarized below. 

a. Pyro Pin Puller Test Results - The pneumatic release was 
nominal, with both pin pullers acting simultaneously. 
Separation was nominal, with no extraneous motion. 

Separation force was calculated to be 2.5 lb. This 
calculation involved the measured separation force of 
12.5 lb and the measured system friction force of 10.0 lb. 

b. Manual Pin Puller Release Test Results - The manual release 
was nominal. Extraction forces were 30.5 and 28.0 lb 


D-97 


respectively, for each manual release pin. Insertion forces 
into the keeper holes were 5.0 and 2.0 lb. The wing separation 
force was calculated to be 2.0 lb, with nominal separation 
motion. The reverse extraction sequence for the second phase 
of the manual test yielded extraction forces of 30.0 and 24.0 
for the same pins. Insertion forces were 2.0 and 1.0 lb. 

Separation again was nominal, with a calculated separation 
force of 2.0 lb. The manual release indication limit switches 
on the support structure malfunctioned after the first manual 
release (see D-Log #4) . Neither would open after resetting 
the support structure latches, which inspection revealed to be 
caused by bent limit switch actuator arms. 

c. Pyro Pin Puller Release Summaries - The pyrotechnic release 
was nominal . A modification to the test specimen was necessary 
to complete the firing circuit installation. A key in one of 
the squib connectors was inadvertently left on and had to be 
removed. Squib firing was nominal, with no pyro shock effects 
or other anomalies seen either on the scene or in the films. 
Separation was non-nominal, in that the separation force was 
calculated to be 6.5 lb, 1.5 lb greater than allowed by the 
CEl Spec (see Appendix B, D-Log, Item 6) . Separation motion 
was again nominal. Unofficial friction measurements indicated 
that the counter balance system friction had increased to 
13.3 lb, 3.3 lb greater than that of the initial measurement. 
Independent conferences with Test Director and Separation 
Mechanics Representatives confirmed that the wing assembly was 
also meant to use 3.2 lb as the corrected separation force. The 
only damage to the test specimen due to testing was that the 
limit switch arms yielded. The pin pullers were damaged 
internally beyond repair, but they were non- flight items which 
are to be replaced with flight units. 

Separation System Test Conclusions 

The test program was satisfactory. All of the test objectives were tested 
and met the program requirements. Except for the release indication limit 
switches, there was no damage to the test specimen. The limit switch arms 
were bent to a workable configuration; this constituted an acceptable 
disposition of the problem. The DAS electronics performed flawlessly, 
firing all four squibs at the proper moment while providing safe operation. 
Separation motion conformed to the expectations of program. Release and 
separation forces measured met the CEl Spec requirements . If the separation 
motion provided by the RMS moves the CTOL in an initial direction parallel 
to the CTOL center axis as planned, then the test results indicate that 
CTOL separation at the CTOL support structure interface can be successfully 
accomplished for non-nominal configurations as welt as the stowed 
configuration of the test . 

Design Review/Bent Pin Analysis 

A bent pin analysis has been performed and is in attached Supporting 
Data as Memorandum PMIC-P361-84-006 and in Technical Memorandum 
PMIC-INT-P341-007 (84) . This analysis shows that no single pin to pin 
short in the connectors within the electroexplosive system circuit 
will cause 50 microamperes of current to flow in the pyro circuits. 

The pyro circuit/power and control pins and wiring will be tested at 
KSC prior to launch as suggested in PMIC-INT-P341-007 (84 ) . Power will 
not be supplied to the experiment during launch. During flight, if one 
pedestal became loose during orbital operations the experiment would be 
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jettisoned since it cannot de-orbit with only one pedestal attached. 

Press #fyellow SPACE#d to continue. ') . 
column = ?column - 1. 
row = ?row - 1 . 
close_window { ) . 

end. (* "Separation System Test Summary"*) 

topic 'attached supporting data', 
column = ? column + 1. 
row = ?row + 1 . 

window (, blue, white, white, ?column, ?row, 74, 16) . 
say ( ' #e 

DESCRIPTION OF THE PYRO INHIBIT RELAY 
PRE-LAUNCH VERIFICATION 

A. Verification of the electrical short across the squib will be 
accomplished prior to installation of each squib by an ohmmeter 
check through the squib interface connector (see attached Pyro 
Control sketch) . 

B. Verification that the Enable, Arm and Fire Relays are in the 
inhibit positions will be done after squib continuity tests 
via ohmmeter test . 

Test Condition/Results : 

1. Primary arm relay (K25) de-energized and primary squib 1 fire 
relay energized - OHMMETER READS #126 2.0 kohms (verifies 
primary arm relay in inhibit position) . 

2. Primary arm relay (K25) and primary squib 1 firer elay (K23) 
de-energized (in inhibit position) - OHMMETER READS #126 58 kohms 
(verifies Primary Squib 1 fire relay in inhibit position) . 

3. Primary arm relay (K23) de-energized and primary squib 2 fire 
relay (K22) energized - OHMMETER READS #126 2.0 kohms (verifies 
primary arm relay (K24) is in inhibit position) . 

4. Primary arm relay (K25) and primary squib 2 fire relay (K22) 
de-energized - OHMMETER READS #126 58 kohms (verifies primary 
squib 2 fire relay in inhibit position) . 

5. Primary enable relay (K21) energized - OHMMETER READS #126 4.0 
kohms . 

6. Primary enable relay (K21) de-energized - OHMMETER READS 
open circuit (verifies primary pyro enable relay in inhibit 
position) . 

7. The redundant squib control relays status will be verified by 
repeating steps 1 through 6 above on the appropriate relays. 

C. The above steps have been incorporated in MSFC Procedure 924. Per 
this procedure, the pyro control cables to the deploy pointing panel 
are disconnected prior to the start of this procedure and will remain 
disconnected during subsequent ground operations. After these cables 
are connected on-pad, the experiment is not powered; therefore, the 
pyro inhibit relays will not be activated until/unless experiment 
separation is activated on- orbit. 
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Press #fyellow SPACE#d to continue. ') . 
column = ?column - 1. 
row = ?row - 1 . 
close_window ( ) . 

end. (‘attached supporting data*) 

topic 'attached letter', 
column = ?column + 1. 
row = ? row + 1 . 

window ( , blue, white, white, 3 , ?row, 74,16) . 
say ( ' #e 

NOTE: THIS PAGE IS INCLUDED AS A REPRESENTATIVE SUMMARY 
STATEMENT FOR THE REPORT 

CONCLUSIONS : 

As previously stated in the analysis, the current pyrotechnic 
qualification requirement employed at MSFC is to subject the 
electrically operated pyrotechnic device to 1 A (dc) at 1 W for 
5 min. The analysis shows that, under worst case conditions, the 
RF energy will cause a current of 45 mA to flow in the NS1 . This 
level is well below the 1.0A value specified as no-fire for NS1 . 

Tests have been performed to determine the susceptibility of NSl 
to RF energy. An NSI, with bare annealed copper wires on its inputs, 
was subjected to 240 V/m at frequencies in the Ku-Band. Test 
conductors were unable to fire the NSI at this level. We expect to 
see only 10 V/m in the payload bay, therefore, we have a large margin 
of safety. 

Our analysis was performed assuming that no shielding is present on 
pyrotechnic circuit wiring. In reality, the pyrotechnic circuit wiring 
(see Attachment 1) , utilizes a silver plated copper alloy shield which 
is highly conductive and provides optimum attenuation. The shielding 
effectiveness is limited only by the gaps in the coverage of the shield. 
MIL-STD-1512 , Tailored for STS, states that shielding shall provide a 
minimum of 85 percent of optical coverage ratio, which the shielding 
used provides . 

In summary, our findings further support the conclusion that the 
pyrotechnic circuitry should not be susceptible to RF energy. 


Press #fyellow SPACE#d to continue. ') . 
column = ? column - 1 . 
row = ?row - 1. 
close_window { ) . 
end. (‘attached letter*) 

column = Tcolumn - 1. 
row = ?row - 1. 
close_window() . 
end . ( * PYROTECHNICS * ) 

topic ' PRESSURE SYSTEMS ' . 
column = ?column + 1. 
row = ?row + 1. 

window ('PRESSURE SYSTEMS' , blue, white, white, 3, ?row, 74, 16) . 
say ( ' #e 

PAYLOAD HAZARD REPORT |NO. ACT -2 

PAYLOAD: Automated Celestial Telescope [PHASE III 
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| DATE 9-15-86 


SUBSYSTEM: Pressure Systems 

HAZARD GROUP: Explosion 

TITLE: Explosion of Pressurized System 


APPLICABLE SAFETY REQUIREMENTS: 

NHB 1700. 7A paragraphs 208.4 and 208.5 


HAZARD CATEGORY 
Catastrophic 
Critical 


DESCRIPTION OF HAZARD: 

The ACT contains pressure vessels, pressure regulators, lines and 
other components which are used to provide the experiment with two 
different mixtures of gases. Explosion or rupture of the vessels 
or other pressure system components could result in fragmentation 
damage in the Orbiter cargo bay resulting in serious damage to the 
Orbiter . 

HAZARD CAUSES: 

1 . Pressure vessel rupture due to inadequate strength or material 
fatigue, the vessels will be filled with gas t a maximum pressure 
of 1800 psi at room temperature (20 deg C) . In a continuous B = 
HOT CASE attitude, analyses show that the temperature could reach 
55 deg C leading to a maximum pressure of 2000 psi. 

2. Regulator, line or other component failure results in damage to 
the Orbiter. 

3. Failure of the regulator results in over-pressure of the ACT. 


HAZARD CONTROLS: 

1. The pressure vessels have been designed and qualified to the 
requirements of MIL-STD-1522A. 

a. The aluminum pressure vessel design is based on Option A 
in MIL-STD-1522A. The vessels are designed to safety 
factors => 2.0 ultimate based on maximum design pressure 
(2000 psi.). Structural design criteria includes the 
burst pressure + flight and crew-induced loads. 

b. A fracture mechanics analysis has been performed to determine 
critical initial flaw propagation. The fracture mechanics 
analysis includes safe-life criteria. 

c. The vessel is designed to be leak tested before burst. 

d. The pressure vessel materials have been selected using 
non-stress corrosion susceptible materials per MSFC-SPEC-522A, 
Table I. 

e. Qualification tests per MIL-STD-1522A. Option A. 

2. Pressure system lines and fittings have been designed to safety 
factors of 4.0 (ultimate) based on 2000 psi MEOP. Other system 
components (except vessels, lines, and fittings) have been 
designed to safety factors of 2.5 ultimate. The system has been 
proof pressure tested to 1.5 MEOP, and leak tested afterwards to 
1.0 nominal operating pressure. Welds have been inspected using 
NDE techniques following system proof test . 

3 . The system is equipped with a pressure relief valve set to 550 psi 
which is 1.1 X the nominal operating pressure of 500 psi. The 
relief valve has been sized to accommodate full flow in the event 
of a regulator failure. Additionally, the ACT Detector is equipped 
with overpressure devices (the ACT Detector is discussed in 
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PHR ACT-D-2) . 

SAFETY VERIFICATION METHODS: 

1. a. Stress analysis including design burst pressure and flight crew 

induced loads . 

b. A fracture control plan and a fracture mechanics analysis, 
including safe-life, have been submitted to MSFC for approval. 
Non-desctructive evaluation has been performed. 

c. Leak before burst failure analysis. 

d. Metallic materials list has been submitted to MSFC Materials 
and Processes Laboratory for approval. 

e. One vessel has been burst tested, and a second vessel cycled 
at 1.5 MEOP (3000 psi) for two times the predicted number of 
operating cycles (3000 psi for 5000 cycles) . Both vessels 
ruptured at levels above the design burst pressure. The 
failure mode of both vessels was leak before burst (LBB) . 

2. Stress analyses were performed. Proof pressure test of the 
system was performed to 1.5 X MEOP with regulators and relief 
valves removed. After the regulators and relief valves were 
installed, the system was leak tested at 1.0 nominal operating 
pressure (500 psi) . The welds in the system were inspected using 
NDE techniques following the system proof test. 

3 . Design Review of the pressure system, and flow sizing analysis 
and test of pressure relief valves. 

STATUS OF VERIFICATION: 

1. a. CLOSED - Design review completed March 18, 1985. See 

attached #m"Description of System"#m. Stress analysis, 
report number ACT- 6 -1211, was evaluated by MSFC 
in May 1985 . 

b. CLOSED - The fracture control plan and fracture mechanics 
analysis (Report No. ACT- 6 -12 13) was approved by the MSFC 
Fracture Control Board (FCB) in June 1985. QC certified 
inspection reports of NDE were submitted at the Acceptance 
Review in April 1986. 

c. CLOSED - Analysis (ACT- 6 -1212) completed March 1985. The 
vessels are leak before burst . 

d. CLOSED - Metallic Materials List of as -built harware approved 
March 1986 by MSFC Materials and Process Laboratory. 

e. CLOSED - The pressure vessel qualification tests were completed 
in November 1985 (see Test Report ACT-6-1275) . A summary of the 
cycle testing is included in #mTable ACT-2- l#m. A summary of the 
pressure vessel log is presented in #mTable ACT-2-2#m. 

2. CLOSED - The stress analysis (Report No. ACT-6-1211) was submitted 
and evaluated by MSFC in May 1985. Proof pressure tests (Report 
No. ACT-6-1305) were performed. Leak test (Report No. ACT-6-1321) 
was performed. QC certified NDE inspection report was submitted 
and approved by MSFC (Report No. ACT-6-1410) . 

3. CLOSED - Design Review was completed in March 1985. Flow Analysis 
of relief valve sizing (Report No. ACT-6-1241) completed March 1985. 
QC certification of relief valve testing (Report No. ACT-6-1289) 
provided at the Acceptance Review. 


APPROVAL | PAYLOAD ORGANIZATION | STS 
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PHASE I 

PHASE II 

PHASE III 

Press #fyellow SPACE#d to continue . ' ) . 

topic ' "Description of System" ' . 
column = ? column + 1. 
row = ?row + 1 . 

window (, blue, white, white, ?column, ?row, 74 , 16) . 
say ( ' #e 

DESCRIPTION OF SYSTEM 

The gas system used in the ACT is schematically shown in Figure 
ACT-2-1. It consists of two gas systems labeled A and B which can 
be summarized as follows : 

Storage Maximum Storage 

System Mixture Composition Volume (L) Pressure (psi) 

A N2 C02 65:35 9400 2000 

B Xe He 75:25 14000 2000 

The ACT detector system (discussed in Hazard Report (ACT-D-2) 
provides internal pressure relief valves to limit input pressures 
to 525 psi. Excess pressure gases are vented to space external to 
the Detector. The gases and all mixtures are controlled internally 
to the Detector. 

The pressure supply system as depicted in Figure ACT-2-1 provides 
dual systems which are identical in design. Each pressure vessel is 
equipped with a manual shut off valve to enable installation. After 
installation, the system is proof pressure tested and the manual 
valves to the pre-charged bottles are opened and remain open until 
post flight operations. Down stream of the manual valve is a two- 
stage pressure regulator which regulates the output to 500 psi. The 
system is equipped with a pressure relief valve (sized for full flow 
in the event of regulator failure) which is set to actuate at 500 psi. 

As depicted in Figure ACT-2-1, items 10 and 2 are high pressure 
manual ON/OFF valves. Items 20 and 23 are regulators which reduce the 
pressure to approximately 500 psia. Item 21 and 22 are relief pressure 
valves with a cracking pressure set at 550 psia. The high pressure 
vessels, the high pressure valves, the regulators and the relief valves 
are all external to the experiment detector system. 

Press #fyellow SPACE#d to continue. ') . 
column = ? column - 1. 
row = ?row - 1. 
close_window ( ) . 

end. (* "Description of System"*) 

topic 'Table ACT-2-1', 
column = ?column + 1. 
row = ?row + 1. 

window (, blue, white, white, ?column, ?row, 74, 16) . 
say ( ' #e 

| QUALIFICATIONS 

I MIN. 
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OPERATE 

PRESSURE 

PROOF 

PRESSURE 

CYCLE (1) 

CYCLE (1) 
PRESSURE 

BURST 

REQTS 

BURST 

PRESSURE 

DEVELOPMENT 

0-2000 

3000 

- 


4000 

5850 

MODEL 







QUALIFICATION 

0-2000 

3000 

500 

3000 

4000 

6200 

MODEL 







FLIGHT UNITS 

0-2000 

3000 

I N/A 

N/A 

N/A 

N/A 


NOTE: (1) Pressure cycling based on predicted 250 operating cycles. 

Press #fyellow SPACE#d to continue. '). 
column = ?column - 1. 
row = ? row - 1 . 
close_window ( ) . 
end. (*Table ACT-2-1*) 

topic 'Table ACT- 2 -2' . 
column = ?column + 1. 
row = ?row + 1 . 

window ( , blue, white, white, ?column, ?row, 74, 16) . 
say ( ' #e Parameter 


1 . 

Maximum Operating Pressure (PSI) 

2000 

2000 

2 . 

Proof Pressure (PSI) 

3000 

3000 

3 . 

Burst Pressure (Design) (PSI) 

4000 

4000 

4 . 

Number of cycles above threshold 

0 

0 

5 . 

Number of cycles above Maximum Operating Pressure 

1 

1 

6. 

Design Cycle Limit 

250 

250 

7. 

Maximum level to which the vessel was pressurized 

(PSI) 3020 

3050 

8 . 

Date of proof test 

12-3-85 

12-6-85 


Press #f yellow SPACE#d to continue. ') . 
column = ?column - 1. 
row = ?row - 1. 
close_window ( ) . 
end. (*Table ACT- 2 -2*) 

column = ?column - 1. 
row = ?row - 1 . 
close_window ( ) . 
end. (* PRESSURE SYSTEMS*) 
end . ( *Appendix C* ) 
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(* MATRIX. KB 

THIS PROGRAM ALLOWS THE USER TO PRINT OUT THE STS PAYLOAD 
SAFETY REQUIREMENTS APPLICABILITY MATRIX (JSC FORM 1090) *) 

(* TURN OFF EDITOR AND DEBUGGER *) 
no_edit_key () . 
no_debug () . 

(* SET INITIAL COLUMN AND ROW POSITION *) 
column = 3 . 
row = 3 . 

(*******★**•**★*★★**•*■★★***■****★* MAIN BODY ******■*■*******■*■************■*■*■*■*•) 


menu_choice = ' ' . 

menu_option is [' PRINT MATRIX' DISPLAY INSTRUCTIONS' , 'RETURN' ] . 

window ('STS PAYLOAD SAFETY APPLICABILITY MATRIX' , blue , white , white , 

?column, ?row, 77, 18) . 

while ?menu_choice <> 'RETURN' 

. then 
ask ( ' 

The applicability matrix provides a systematic approach for 
identifying those #mNHB 1700. 7#m requirements applicable to a particular 
payload element. The purpose of the matrix is to provide objective 
evidence that the #mPED#m has considered every requirement of NHB 1700.7 
in assessing the safety of the proposed design. The PED will initially 
submit the matrix at the Phase 0 Review and update the matrix for 
each future PED safety data submittal . 

Please choose one of the following: ' ,menu_choice, ?menu_option) 

and 

if ?menu_choice = 'DISPLAY INSTRUCTIONS' 
then do ( ' Instructions' ) 
else 

if ?menu_choice = 'PRINT MATRIX' 
then do ( ' Print Matrix' ) 
else 

if ?menu_choice = 'RETURN' 
then 

column = ? column - 1 

and 

row = ?row - 1 
and 

close_window ( ) . (* MAIN WINDOW *) 

(* TOPIC MARK *) 
topic mark (f ind_string) . 
column = ?column + 1. 
row = ? row + 1 . 

text is read ( 'nasaterm.dat ', concat ('//', ?find_string) ,' /end' ) . 
window (?f ind_string, blue, white, white, ?column, ?row, 72 , ) . 
say (?text) . 
column = ? column - 1. 
row = ?row - 1 . 
close_window () . 
end. (* topic mark *) 
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(**************************** RELATED TOPICS ******************************) 


topic 'Print Matrix', 
column = ?column + 1. 
row = ?row + 1 . 

window ('PRINT MATRIX' , blue, white, white, ?column, ?row, 76, 17) . 
menu_choice2 = ' ' . 

menu_option2 is ['PRINT MATRIX' , 'RETURN'] . 

while ?menu_choice2 <> 'RETURN' 
then 

ask (' This selection invokes a DOS program which provides 

a printout of the STS Payload Safety Requirements Applicability 
Matrix. The program is designed to print the matrix solely on a 
laser printer. If you do not have access to a laser printer, then 
a copy of the matrix has been included in the rear of the user#3 9s 
manual for you to copy at your discretion. 

Printing the matrix may take anywhere from a few seconds to a 
few minutes depending on the amount of internal memory that your 
printer has available. Please do not be alarmed by the delay. 

Please make your selection. ' ,menu_choice2, ?menu_option2) 


and 

if ?menu_choice2 = 'PRINT MATRIX' 
then 

row = ?row - 1 
and 

column =? column - 1 
and 

close_window ( ) 
and 

collect 0 
and 

dos ( ' MATRIX . EXE' , restore) . 

if ?menu_choice2 = 'RETURN' 
then 

column = ?column - 1 
and 

row = ?row - l 
and 

close_window () . (* PRINT MATRIX *) 

end. (* Print Matrix *) 


topic 'Instructions', 
column = ?column + 1. 
row = ?row + 1 . 

window ('FILLING OUT STS PAYLOAD SAFETY MATRIX' , blue, white, white , ?row, 
?column, 76 , 17) . 

say ( ' STS PAYLOAD SAFETY REQUIREMENT APPLICIBILITY MATRIX 

JSC FORM 1090 

This is an assessment of the applicability to the payload 
of the technical requirements of #mNHB 1700. 7#m. The matrix is 
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to be updated at each safety review. 


Blocks 1-4 


Self-explanatory 


Block 5 #mPAYLOAD ELEMENT#m - Major payload element 

subsystems are listed. Typically, a subsystem 
is a "black box" (a self contained housing) having 
one or more functions, for example: power supply 

(microprocessor) ,- power supply (microprocessor, 
command generator, data storage) ; sensor assembly, 
etc . 


Block 6 NHB 1700.7 REQUIREMENTS - Using the legend in 

#mBlock 8#m as a guide, enter the appropriate 
symbol in the matrix. 

Blocks 7 & 9 Self-explanatory 


Press tfyellow SPACE#d to continue.'). 


column = ? column - 1 . 
row = ?row - 1 . 
close_window ( ) . 
end. (* Instructions *) 

topic 'block 8' . 

column = ? column + 1. 
row = ?row + 1. 

window ('BLOCK 8 (LEGEND) ', blue, white, white, ?column, ?row, 75, 16) . 
say ( ' 

The following symbols are used when filling out the STS Payload 
Safety Applicability Matrix: 

NOT APPLICABLE 

/ APPLICABLE: 

NO HAZARD IDENTIFIED 

X APPLICABLE: 

HAZARD IDENTIFIED 

#219 WAVIER DEVIATION 
REQUIRED 

Press #fyellow SPACE#d to continue.'). 


column = ? column - 1. 
row = ?row - 1. 
close_window ( ) . 
end. (* block 8 *) 
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